G H N E PLAN 



so, 



Delphi is 
the Answer 



Normally I make it a rule not to 
recommend any programming 
tool that I haven't used to 
develop a program from 
scratch. I'm going to break that 
rule to recommend Borland's 
D elphi. I 've only used it to 
develop a program that trans- 
lated from Celsius to Fahrenheit degrees, 
but the only reason I'm not altogether 
committed to D elphi is (I 'm blushing as I 
type this) I've never learned Pascal. Well, 
I'm going to learn it now. For Windows 
developers, and for W indows game devel- 
opers especially, Delphi is so far ahead of 
the competition it'sembarassing. 

The world of Windows development 
has always been one of compromise. T ools 
such asVisual Basic offer immediate grati- 
fication when moving from writing code 
to seeing your program run, but the per- 
formance has always suffered in compari- 
son with compiled code. On the other 
hand, compiled C++ offers near-optimal 
performance, but all but the most trivial 
programs have compilation times mea- 
sured in minutes, not seconds. Program- 
mer productivity vs. compiled perfor- 
mance. Pleasure for the programmer vs. 
pleasure for the user. The iron compro- 
mise of W indows 

Delphi makes no compromises. For- 
get the claims of how many hundreds of 
thousands of lines of code are compiled 
per minute, the point is that D elphi's 
speed of compilation is such that the 
move from editing to debugging is seam- 
less; when your screen flickers you think a 
background compilation process is being 
spawned but, in fact, you're seeing the 
results of thefinal link. 

Delphi is being marketed toward the 
current marketing darling, corporate 
developers, and there's no question that it 
will cut a swath through the ranks of Visu- 
al Basic and PowerBuilder users out there. 
H owever, game developers have even more 



to gain by examining D elphi. W hy? T he 
huge, relatively untapped W indows game 
market. With Delphi, you can useWinG 
to get your images on screen relatively 
quickly, and you also can get many more 
compile-link-debug cycles in a program- 
ming session. W indows game develop- 
ment inevitably involves hit-and-miss pro- 
gramming challenges (no matter how 
experienced you are, the W indows API 
can surprise you), so more cycles means 
faster development. W hen you're done, 
your programs run at compiled speeds. 

Also, Delphi abstracts the W indows 
API. If this abstraction isn't good enough 
for you, feel free to create your own. Del- 
phi's code reuse infrastructure is excellent, 
with full object-orientation and the ability 
to package groups of objects together as 
functional components Develop an engine 
for isometric projection, and you can save 
it as its own package and use it as a start- 
ing point for future games. 

Delphi is based on Object Pascal 
which, as I said, is a new language to me. 
H owever, it's very straightforward— C ++ 
it ain't. Although I've already discovered 
some things that I don't like (the keyword 
private doesn't act the way I think it 
should, and I can never figure out where 
semicolons are expected), I 've also already 
come up to speed on the basic structure of 
the language. You should have no trouble 
picking it up and, just as importantly, you 
shouldn't have any trouble finding new 
programmers fluent in it. 

You'll be reading a lot about Delphi 
in the corporate programming magazines, 
where it will be primarily lauded for its 
ability to create database applications. But 
I'll make a bold prediction— the most suc- 
cessful W indows game of 1996 will be 
written entirely in Delphi. Until that ships, 
I'll be busy learning where the stupid semi- 
colons go. ■ 

Larry O'Brien 
Editor 
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S E Z ! 



by Our Readers 

Something on your 
mind? II response to on 
article, o query about 
code, a little poem or 
dittu. perhaps? If p 
have anything to get 
off pr chest, please 
do. Nell probably 
print it here. 



More to 
the Mys 



Dear Editor: 

I would like to offer a few suggestions to sup- 
plement Andre LaMothe's article "The Myste- 
rious Mode 13h" (Sept. 1994). 
I am a shareware game programmer who has 
been using Mode 13h for about two years now. I 
can see at least one obvious ways to speed up 
the graphics functions Mr. LaMothe described. 
The first would be to avoid using the palette 
ports (0x3C7/0x3C8) as much as possible. One 
blatant way that I can see to do this would be to 
eliminate reading the port whenever the pro- 
gram needs the value of a specific register. 
Instead, simply create a structure: 



typedef struct { 

unsigned char red [256] 
unsigned char grn[256] 
unsigned char blu[256] 
} PaletteStr; 



Clear the structure in the beginning of the 
program, and also clear the palette (set all 
"bucket" values to (0,0,0)) using the write 
port. Then, whenever the structure is updated, 
simply update the array value as well. That 
way, a function can simply look up a value in 
an array instead of having to write/read to a 
port. This also streamlines the color cycling 
function by eliminating the overhead associat- 
ed with procedure calls (about five processor 
cycles). Simply rotate the array, then push the 
whole thing out to the VGA card when the cycle 
function is done. 

Mason McCuskey 
via e-mail 

MORE READING MATTER 
Dear Editor: 

I enjoy your magazine, I find it helpful and 
interesting. I would like to see the price go 
down or the amount of material in it go up, 



te ry 



but I still think that it's worth it. I think it 
would be enormously helpful if after each arti- 
cle you gave a brief reading list of good books 
that provide more information about a partic- 
ular topic. For instance, in the December issue 
you featured a great article on Mode C (umm... 
excuse me.. .Mode X) but I would like to know 
of a book that would give a beginning-to end 
breakdown of the technique. This would help 
those who aren't quite as technically 
advanced as some, and keep the folks who are 
advanced happy. Plus the market for computer 
books is so full of crap that it would be nice to 
have someone who knows something suggest 
good books. 

Gideon Stocek 
via e-mail 

Editor Larry O'Brien responds: 
Good suggestion! We're running book reviews 
regularly to try to cut through the crap (see 
Dean Oisboid's article on page 48). One sugges- 
tion: don't buy a book that calls you stupid. If 
the title's condescending, the text will be as 
well. 



WHERE'S THE CODE? 
Dear Editor: 

I'm looking for the code for Carl Muller's 
article "Hitting on Collision Detection" 
(Sept. 1994). The article states that it is 
available on CompuServe, but I can't find it. 
Do you have any more detailed information on 
exactly where it is, the filename, forum, and so 
on? I'd also like to know if it's available on any 
ftp sites. 

Leonard Guy 
via e-mail 

Editor Larry O'Brien responds: 
On CompuServe, Go SDFORUM and visit our 
library. Or set your browser to the 
/pub/gdmag/src ftp directory of whiz.mfi.com. 
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CROSSFIRE 



Media Vision 
Picks Up 
The Pieces 



Alex Dunne 

"Nell be quiet, but 
we'll be here." 
says Robert Brouinell. 
CEO of Media Vision. The 
company toon some 
recent blows — many 
of them self-inflicted. 
How it's bach with a 
hinder, gentler 
business sense. 



Digital entertainment is often 
in the media spotlight. Usu- 
ally we hear about technolog- 
ical breakthroughs, though— 
rarely are high-tech compa- 
nies involved in controversies. 
There have been some 
notable exceptions, though, 
and surely Fremont, Calif.-based M edia 
Vision stands out as a Silicon Valley 
soap opera. M edia Vision scraped bot- 
tom last summer when it filed for 
C hapter 11, ironically due to the lack of 
vision that the company— led by former 
CEO Paul Jain— had. H owever, this 
year M edia Vision emerged from bank- 
ruptcy and is attempting a comeback 
with the help of new management and 
capital. The company has refocused on 
its core technology, audio cards, and is 
in the process of rebuilding the public's 
confidence and researching new audio 
technologies. 

The company's problems began 
back in 1993. M edia Vision was well 
positioned in the red-hot multimedia 
market, thanks to its Pro AudioSpec- 
trum sound cards and multimedia 
upgrade kits, yet ongoing price wars 
with rival sound card makers like Cre- 
ative L abs and an overextended product 
line were taking their toll on the com- 
pany. In October of 1993, M edia 
Vision rolled out a plan to produce 
CD-ROM games, instantly making it a 
major player in the game industry. 

Asa complementary product line, 
the company's announcement was well 
received by investors. N ews of the 
game venture helped propel the compa- 
ny's stock. M edia Vision shares reached 
$46 in January 1994— barely 14 



months after the company went public 
at $15. Although the stock was gener- 
ally regarded as overvalued, nobody 
realized how much so until a few 
months later. 

Greenberg Blows 
The Whistle 

H erb G reenberg, a columnist for the 
San Francisco Chronicle, did someinves- 
tigating and discovered that M edia 
Vision had falsified sales records and 
engaged in shady business practices to 
paint a better picture of the company's 
finances. According to Greenberg, 
M edia Vision secretly rented ware- 
houses to hide returned merchandise, 
pressured engineers and sales reps to 
get defective products out the door, 
offered huge incentives to distributors 
and retailers who ordered large quanti- 
ties of merchandise (known as "channel 
stuffing"), and most egregiously, doc- 
tored shipping papers to charge a large 
quantity of multimedia upgrade kits to 
a previous fiscal quarter. 

Jain, who some believe was the 
force behind the company's question- 
able practices, was a favorite target in 
G reenberg's columns. ne of G reen- 
berg's columns even poked into Jain's 
personal life, referencing allegations 
that he illegally used M edia Vision's 
corporate assets to "court women." I 
bet Jain loathed opening up his morn- 
ing paper for fear of what he'd read in 
the business section. 

W hen these stories surfaced, the 
FBI and the SEC quickly took notice. 
On M ay 9, 1994, the two agencies 
began a probe into securities violations 
committed by the company. M edia 
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CROSSFIRE 



Brownell's humili- 
ty contrasts his 

company's brazen 

past, and he's cir- 
cumspect about 
the hard lessons 

the company has 
learned uiith 
consumers and 
resellers. 



Vision's stock, which had been plum- 
meting in recent weeks due to questions 
surrounding the company's financial 
status, closed that day at 2 7 / 8 . One 
week later, Jain and three other corpo- 
rate officers resigned. 

I n the wake of Jain's departure, 
Robert Brownell, the vice president of 
domestic sales, took over as C E . 
Brownell inherited the unenviable posi- 
tion of rebuilding the company, and 
one of his first actions was selling the 
company's game publishing arm, which 
included The Daedalus Encounter and 



Critical Path, to Virgin Interactive. 

Unfortunately for the company, 
Brownell's move didn't stave off bank- 
ruptcy. Two major creditors balked at 
the company's reorganization plan, so 
on July 25th, 1994, M edia Vision filed 
for Chapter 11. The clincher followed: 
the company admitted that its $20 mil- 
lion profit for 1993 wasn't quite accu- 
rate. I n fact, there was no profit for the 
previous year: the company actually lost 
$99 million. M edia Vision attributed 
the revision in numbers to unaccounted 
product returns and marketing costs, 
improperly recorded sales, and doubtful 
accounts. 

Since it came clean with investors 
last summer, M edia Vision has taken 
steps to rebuild itself. In August, it 
secured a $10 million credit line from 
T rust C ompany of the W est (T C W ) to 
help fill $24 million in backlogged 
orders and prepare for heavy demand 
during the C hristmas shopping season. 

n D ecember 30th, M edia Vision 
emerged from Chapter 11. Its stock, 
which just a year earlier had been trad- 
ing in the 40s, was canceled and worth- 
less. To cover previous debts, the com- 
pany issued 20 million shares of new 
common stock, of which TCW will 
own 43%. Two TCW officers sit on 
M edia Vision's board of directors. The 
company, once composed of close to 
500 employees, is about half that size 
now. M edia Vision has also entered 
into an agreement with the SEC, 
according to which the agency will rec- 
ommend that no enforcement action be 
taken against the company, as long as 
M edia V ision cooperates with the SE C 
and the Dept. of Justice. 

From the CEO: Brownell's 
Plans To Rebuild 

I recently spoke with Robert Brownell, 
and he explained M edia Vision's plans. 
H is humility contrasts his company's 
brazen past, and he's circumspect about 
the hard lessons the company has 
learned with consumers and resellers. 

"Our position is more one of con- 
trolled growth. W e're not just chasing a 
growth curve to see how much in sales 
we can ring up. We're very cautious 



when dealing with the reseller channel 
that we don't put too much product in, 
[rather] that we put the right product 
in. W e don't try to give [resellers] eight 
kits when we know only two of them 
are going to sell. We're not in that 
mode anymore. I guess some of the 
competitors still do that," Brownell 
commented. 

Brownell on the practice of chan- 
nel stuffing: "That happens everywhere. 
[If] you continue to throw out new 
products and... you don't deal with 
[your older products] as rapidly as you 
should, then you have a problem. We 
monitor the sell-through at the retail 
level very closely, to make sure that we 
don't put our products in that position. 
And we don't do deals with the reseller 
channel that could put us in that posi- 
tion. We just say, 'Buy what you think 
you can sell. H ere's our pricing. If this 
works for you, then great. W e'll support 
you.'" 

W hat are Brownell's goals for 
M edia Vision in 1995? "W e haven't 
publicly stated our dollar goal, and we 
probably won't until the end of the first 
quarter. But [with respect to] my goals 
for the company, the first... was to get 
through bankruptcy. To get our house 
in order. And now we're in that posi- 
tion. We have developed a plan to go 
forward, [and] we need to execute on 
that plan... 1995 should be a quiet year 
for us." 

Brownell has stated that M edia 
Vision will get back to its core market. I 
asked him to elaborate on this plan: 
"0 ur core technology is audio, graphics, 
and actually, video. One of the areas 
that we've been working on over the last 
several years is waveguides. We have 
one of the licenses out at Stanford and 
we think we're the farthest along, and 
we have a working chip at this time. 
W e hope that this will translate into 
some products in the fourth quarter, but 
I don't think it will have a major impact 
until next year. We feel that's our best 
shot, and we want to build our company 
around it. It will differentiate us in the 
market." 

It was encouraging to hear that 
waveguides is an integral part of the 



10 GAME DEVELOPER • APRIL/ MAY 1995 



CROSSFIRE 



company's plans. W aveguides is a soft- 
ware technology that was developed at 
Stanford University's Center for Com- 
puter Research in M usic and Acoustics. 
It uses algorithms to mimic the subtle 
characteristics of musical instruments 
and human voices. 

"[Waveguides] is professional 
audio at consumer prices," Brownell 
explained. "You can develop sounds and 
you can create new sounds that have 
never been developed before. If you 
wanted to know what a 10- foot-long 
trombone sounded like, you could do it. 
A guitar with a 15- foot-long neck. You 
can actually recreate the [sound of] 
vocal chords and how they interact with 
the mouth cavity. W hen you hear a 
clarinet, you hear the [player's] breath. 
W e think this is the next standard of 
sound. W e'll be showing it to game 
developers soon." 

Brownell also indicated that due to 
M edia Vision's past financial troubles, 
the company was no longer pushing for 
a VESA standard for audio cards (see 



"Sounding Out the VESA Audio Stan- 
dard" by J on Burgstrom, June 1994). 

Does M edia Vision have any plans 
to reenter the game development market? 

"N o. I shouldn't say never, but it's 
something that takes a lot of focus and 
attention. And because of the fact that 
it's not our core strength, and that we 
don't devote 100% of our time to it, it's 
a difficult business. It's a 'hits' business. 
The cost of developing [games] is so 
high— it requires a lot of cash and 
investment before you get a payoff. I 
feel that it's better left to people who 
are devoting 100% of their attention to 
it. It's a million dollars to develop a 
title— that's before promotion costs. 

"The start we got off to in that 
business wasn't very good. W e didn't 
have enough to sustain it. [Of] our 
existing titles, two or three were good, 
and the rest were O.K. I liked a lot of 
the [games] that were coming down the 
pipe, but it would have been another 12 
to 24 months before they started to 
show any returns. And, at the same 



time, you have to continue to develop 
because you can't stand still. So I really 
do believe it's best left to people who 
just deal with software." 

Brownell had some interesting 
insights into the multimedia upgrade 
market, in which he sees a second 
round of upgrade kit purchasing. This 
coming round of purchasing will be 
fueled by people who already bought an 
upgrade kit or PC containing a single or 
double-speed C D -RO M drive and 
standard 8-bit or 16-bit sound card, 
and who would like to move up to a 
quad-speed unit and a superior sound 
card. Brownell doesn't see this second- 
round market growing as explosively as 
the first round of kit sales. 

W hat's his take on M edia Vision's 
competitor, C reative L abs? 

"I know that they have a lot of 
product out in the channel. Again, 
we're not chasing [Creative Labs' pro- 
jected] growth curve. They said they 
were going after a billion dollar [in 
sales] year, and that's too risky for us 
right now. If we build good products, 
and make it easy for the customer to use 
them, ...do the right price points, the 
sales will come. And whatever [the 
sales] are, they are. I f you do a good job 
and you support the customers, your 
sales will increase. But if you try to 
force it, and think that no matter what 
you put in the kit is going to sell at 
whatever price point, you're only fool- 
ing yourself in the long run. It will be 
interesting to see how the industry 
shakes out. We'll be quiet, but we'll be 
here. Especially through '95. W e gotta 
prove to people that we can do it. 
Deliver what we said we were going to 
deliver on." 

What has Brownell heard about 
ex-CEO Paul J ain? 

"Nothing. I haven't really talked 
with him since he left. H e might have 
already started another company, but 
I'm not sure." 

T here's hope for this company. ■ 

Alex D unne is contributing editor for 
Game Developer magazine. Contact him 
via email at 75010.2665@compuserve.com 
or through G ame D eveloper. 
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BIT BLASTS 



Hair in a 
Can it Ain't: 



Nicole Claro 

Animation, animation, 
animation! It seems 
lihe that's what it's all 
about. But it's also 
about upgrades, 
design, textures uiochy 
and wonderful and the 
hairdo to end all hair- 
dos [Ted Danson, eat 
your heart out]. 



One of the greatest challenges 
facing game today's game 
animators is not how to cre- 
ate amazing graphics, or how 
to render realistic morphs, or 
even how to incorporate 
believable live-action video 
into their games. There's a 
pursuit far thornier than any of these, 
and that is.. .hair. 

Yes, hair. W hether the character 
needs a M ike-Brady perm, a floppy 
toupee, or a purple mohawk, designers 
have always had difficulty creating lus- 
cious head- topping or body-covering 
tresses that are true- to- life. Until now, 
that is. Alias CompuH air will put an 
end to bad hair days for three-dimen- 
sional characters forever. The new 
product from Alias uses an advanced 
computer technique called particle sys- 
tems, which uses the power of Silicon 
Graphics workstations to render real- 
looking hair and fur. 

Users can customize the hair 
using options for color, transparency, 
length, curliness, and thickness. The 
Alias Digital OptiF/X system, the 
main component of Alias PowerAni- 
mator 6.0, integrates the Alias particle 
system generator to create interactions 
between particles and NURBS or 
polygonal- based models in the scene. 
It's this integration that lets you com- 
bine hair and fur with other three- 
dimensional modeling and rendering 
elements like wind, gravity, and light, 
to create waving hair, shadowed hair, 
glowing hair, and the like. 

W ait, there's more! I f you want to 
find out even more about this, simply 
stay up until 1:00 a.m. sullenly driving 



the channels with your remote until 
you seethe infotisement. Actually, you 
can join the Alias H air Club for Ani- 
mators by accessing A lias's W orld 
W ide W eb server at www.alias.com. 
Perhaps you'll meet the organization's 
president who, I understand, is also a 
client. 

For More Information Contact: 
Alias Research Inc. 
110 Richmond St. E. 
Toronto, Ont, Canada M5C-1P1 
Tel: (416) 362-9181 

Moves of Stucco and Velvet 

Sure, hair's important— who hasn't 
been hair- obsessed at one time or 
another (especially during adoles- 
cence)? But there are lots of things 
that have nothing to do with live char- 
acters that can often make or break a 
game. Fractal Design's Really Cool 
T extures recently came on the market as 
add-on packages for use with Fractal 
Design Painter and Fractal Design 
Sketcher. 

The company's newest series 
increases the number of paper grains 
and patterns available to users of 
Painter and Sketcher. You can create a 
texture and use it as a background or 
link it to any natural-media tool to 
allow you to paint with textured ink or 
paint. The series comprises M iles of 
T iles, W alls and Reliefs, G rains and 
W eaves, and Patterns and N ature. 
R eally C ool T extures costs $29.99. 

For More Information Contact: 
Fractal Design Corp. 
335 Spreckels Dr. 
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Aptos, Calif. 95003 
Tel: (408) 688-5300 

Quichdrouj and More 

Electric I mage I nc.'s E lectricl mage 
Animation System now supports 
Apple's quickdraw three-dimen- 
sional API and metafile format. 
With this technology, users can view 
their animation projects in real time, as 
they are creating them. Accelerated 
three-dimensional graphics can only 
increase the speed of the user interface, 
the company says. 

Once available only for high-end 
workstations, the new API and three- 
dimensional cards will soon be open to 
all customers. E lectric I mage will release 
two versions— one for Power M acintosh 
and one for M acintosh. Both versions 
import, render and animate objects from 
multiplatform modeling programs and 
both include sync sound animation, 
deformations, and various plug-ins. 
E lectricl mage Power M acintosh 2.1 and 
M acintosh 2.0 sell for $7,495. Owners 
of E lectricl mage 2.0 (M acintosh ver- 
sion) can upgrade to the Power M acin- 
tosh 2.1 versions for $495. 

For More Information Contact: 

Electric Image Inc. 

117 E. Colorado Blvd., Ste. 300 

Pasadena, Calif. 91105 

Tel: (818) 577-1627 

Toonz Colore 

Microsoft has just released version 
3.5 of Softl mage T oonz (the soft- 
ware formerly known as C reative 
Toonz— not to be confused with 
the rock star) for the Silicon Graphics 



platform. The product includes a com- 
plete range of functions based on tradi- 
tional eel-drawing processes, such as 
audio input to scanning, pencil test, set 
palette, special effects, and compositing. 
By adding separate modules, you can 
customize Softimage Toonz for scan- 
ning, ink and paint, and rendering. 

Version 3.5 includes enhanced ver- 
sions of many of the features available on 
past versions as well as new modules and 
utilities, and several major bug fixes. Soft- 
Image Toonz 3.5 features an icon- based, 
simpler user interface; X-sheet, an expo- 
sure sheet based on the ones used in tra- 
ditional animation; a camera stand, which 
adjusts eels and layers to size and back- 
ground, that exists in the same interface 
as the X-sheet; and resolution indepen- 
dence, which lets users select film, video, 
or H DTV output. Softl mage T oonz 3.5 
costs approximately $16,995, with various 
modules available at extra cost. 

For More Information Contact: 

Microsoft Inc. 

1 Microsoft Wy. 

Redmond, Wash. 98052-6399 

Tel: (206) 882-8080 

Ooh. Cyberspace! 

Hutodesk has upgraded its Cyber- 
space Developer Kit (CDK). 
Release 2 is a W indows NT /32s- 
based upgrade of the toolset for 
three-dimensional visualization and sim- 
ulation. CDK Release 2 features a com- 
prehensive code set that incorporates 
170 C++ classes and more than 1,400 
functions that lets professional users, 
such as game developers, create interac- 
tive, three-dimensional environments. 



It's rendering-solution independent and 
can be extended to support future hard- 
ware- and software- based rendering 
methods. CDK Release 2 costs $1,995. 

For More Information Contact: 
Autodesk, Inc. 
2320 Marinship Way 
Sausalito, Calif. 94965 
Tel: (800) 879-4233 

Further Rendering 

Hnd in other upgrade news, Render- 
M orphics has released version 2 of 
Reality Lab, its three-dimensional 
API. With full cross- platform inte- 
gration and compatibility, Reality Lab 2 
provides new special effects options and a 
feature set that includes depth cueing, 
projected shadows, and more. T he func- 
tionality of version 1 is further enhanced 
through I mmediate mode, a module that 
allows low-level control over polygon 
lighting and rendering through direct 
access to vertices and normals. This 
improves custom lighting and transform 
effects, warping, twisting, and bending of 
object, and procedurally defined objects. 
Reality Lab 2 supports W indows, DOS, 
System 7 and UN IX and contains specif- 
ic Pentium optimization, which ensures 
that it is even faster than version 1. 

For More Information Contact: 
RenderMorphics Ltd. 
Unit 15, The Turnmill 
63 Clerkenwell Rd. 
London EC1M 5NP U.K. 
Tel: 44 (0) 71 251 4411 

N icole Claro is managing editor for 
G ame D eveloper magazine. 
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Pe r s pec ti ve 
Texture Mapping 
Part: I: Foundations 



Figure 1. Textured Checkerboard 
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If there is one technical feature 
today's high-performance three- 
dimensional games must have, it is 
texture mapping. The technique of 
texture mapping stretches across 
almost every genre of game, from 
role-playing games like Ultima 
Underworld and System Shock, 
through simulators like Indy Car Racing 
and W ing C ommander III, to action 
games like D oom and D escent. 

Given its popularity, you'd think 
there would be a wealth of information 
available on how to actually write your 
own perspective texture mapper. You'd 
be wrong. 

W hen I was researching this article 
(actually, when I was trying to figure out 
if an article on perspective texture map- 
ping was even needed), I looked high 
and low for intuitive descriptions and 
working sample code, but not much 
exists. M ost articles on the Internet 
describe affine texture mapping, and the 
few perspective texture mapping articles 
I did find on x2ftp.oulu.fi, an excellent 
game programming ftp site managed by 
Jouni M iettunen, use overly complicated 
descriptions and aren't accompanied by 
working code. Even old standbys, like 
Computer Graphics: Prindplesand Practice 
(Addison-W esley, 1992) by James D. 
F oley, A ndries van D am, Steven K. 
Feiner, and John F. H ughes (commonly 
called Foley and van Dam, much to the 
chagrin of Feiner and H ughes, I 'm sure) 
and the bible of texture mapping, D igital 
I mage Warping (1990, IEEE Computer 
Society) by George Wolberg, are woeful- 
ly inadequate if you actually want to 
write a texture mapper, especially one 
fast enough to be compelling for games. 



I'm going to address this lack of 
documentation in this and the second 
part of this article. First, using nothing 
more than basic algebra and geometry, 
I'll show you an easy-to- understand 
mathematical foundation, for how and 
why perspective texture mapping works. 
I 'II also provide sample code to imple- 
ment the naive algorithm. I n the second 
installment, we'll speed it up to interac- 
tive performance. 

Assumptions, Definitions, 
and Concepts 

If we want to cover everything in two 
articles, we're going to have to move 
pretty fast. To do this, I need to assume 
you know a bit about three-dimensional 
graphics. If you don't know how object 
space, world space, view space, and 
screen space interact, or you don't know 
what those terms mean, you should 
probably pick up a book like Foley and 
van Dam before reading this article. 

The term "texture mapping" 
describes a whole family of techniques, 
but for these articles, we'll define texture 
mapping as drawing a planar polygon as 
if a bitmap was glued to the polygon's 
face. This bitmap goes through the same 
transforms (or at least looks like it does) 
as the polygon, so if we view the polygon 
almost edge on, the bitmap, or texture, 
will look like it's edge on as well. Figure 
1 shows a checkerboard viewed at an 
angle. You can see how the squares get 
smaller as they recede, just as you'd 
expect. 

To accomplish this mapping, we 
associate a texture bitmap with each 
polygon and texture coordinates with 
each vertex of the polygon. In addition 



to the normal (x,y,z) triplet to define a 
vertex in three dimensions, we specify the 
texture coordinates u and v. These coor- 
dinates are two-dimensional coordinates 
into the texture bitmap, and the pixels in 
this bitmap are sometimes called texels. 

To make things easy to visualize, 
our diagrams and equations will be in 
two dimensions— think of working in a 
slice through the three-dimensional 
space— but our results extend easily into 
three dimensions. 

Perspective Projections 

M ost three-dimensional game graphics 
are based on perspective projections. Per- 
spective projections make distant objects 
seem smaller than closer objects and dis- 
tort angles so scenes look realistic. 

The basic equation for the perspec- 
tive projection uses similar triangles that 
share a vertex at the origin (the view- 
point). If we take the point (x ,z ) (ignore 
the u coordinates for the time being) and 
project it onto the dashed vertical z=d 
line in Figure 2 to give us (x ',d), the 
equation for the relationship between 
these two points is: 



z 



(1) 



X Q 

d 



I n other words, the ratio of the 
height of the triangle formed by ((0,0), 
(V,d), (0,d)) to the length of its base is 
the same as the ratio of the height of the 
triangle formed by ((0,0), (x^z,,), (0,z )) to 
the length of its base. If we assume d=l 
for the current example, and generalize 
this equation to all unprojected points 
(x,z), we get: 



If we view the z=d line as the one- 
dimensional equivalent of the two- 
dimensional screen plane (pretend you're 
looking down on the plane from above, 
so you can only see it as a line), E quation 
1 says we can generate screen coordinates 
(x' for values of x) by dividing the unpro- 
jected object coordinates by their z val- 
ues. This is the perspective projection in 
its essence. 

Mapping Direction 

In three-dimensional graphics, we con- 
sider transforming from object to screen 
coordinates moving "forward," so Equa- 
tion 1 is called a forward mapping— it 
projects the source polygon forward onto 
destination pixels. T o use a forward map- 
ping for texturing a polygon, you step 
along the polygon in object space and 
project each generated point forward to a 
destination pixel position. Forward map- 
pings don't work very well for texture 
mapping, however, because it's hard to be 
sure how far to step in the source so that 
the projected coordinates don't skip or 
overwrite any pixels in the destination. 

Backward mappings, on the other 
hand, allow us to step in screen space, 
processing each pixel exactly once. If we 
manipulate E quation 1 to give us a back- 
ward mapping from x' to x we get: 



x =x z 



(2) 



T his tells us we can generate values 
of x from values of x' if we multiply x' by 
z. We can easily generate the desired u 
texture coordinate once we have x, but 
first we must find the correct z to feed into 



Chris Hecker 

Little has been writ- 
ten nn perspective 
texture mappers, on 
invaluable feature of 
any high-perfor- 
mance game. This 
month, Chris Keener 
fills the void ujith the 
first of a tiuo-part 
article on the subject. 
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Equation 2 (we already know x' because 
it's the current pixel we want to write). 

It would be great if we could gener- 
ate z values directly from x' values using a 
simple linear interpolation. W e often use 
linear interpolations in graphics in the 
form of digital differential analyzers 
(DDAs), and fixed and floating-point 
interpolations, but we know linear inter- 
polation is only accurate when we are 
interpolating a linear equation. Let's 
explore the relation between x' and z to 
see whether they are linear with respect 
to one another, which in turn will tell us 
if we can use linear interpolation to gen- 
erate z from x'. 

A linear equation is any equation of 
the form: 

y=AX+B (3) 

for any real values of A and B (this is 
called the si ope- intercept form, where A 
is the slope of the x,y line, and B is the y- 
intercept, or value of y when the line 
crosses the y axis). T hat is, as x changes 
by a constant amount, y changes by a 
constant amount proportional to the 
change in x. 

To find the relationship between x' 
and z, we first take the equation for the 
unprojected line in object space, x =Az + 
B. The actual values of the constants A 
and B are based on the endpoints of the 
line segment, and are irrelevant to this 
derivation. Next, we substitute this into 
Equation 2 to get an equation in z and 
x', and solve for z: 

Az +B =x'z 
B =z(x'-A) 

and finally: 



Equation 4 is definitely not a linear equa- 
tion with respect to x', so we can't direct- 
ly compute z incrementally from values 
of x'. H owever all is not lost, because a 
little algebraic manipulation gives us: 



Equation 5 is a linear equation with 
respect to x'. The only problem is, it's a 
linear equation of 1/z with respect to x', 
not z itself! We can use Equation 5 to 
linearly interpolate values of 1/z and take 
the reciprocal at each pixel to get the real 
value of z. I n other words, we can linearly 
interpolate 1/z and divide x' by 1/z to 
generate values of x according to 
E quation 2. T hese values of x allow us to 
compute values of u that we can use to 
look up the correct color from the texture 
bitmap to store in x'. Voila, perspective 
texture mapping. 

It turns out we can compute u 
directly instead of computing x, saving a 
step and simplifying our lives. By defini- 
tion in Equation 1, x/z is linear in screen 
space (it's actually equal to screen space, 
which is about as linear as you can get!). 
Just as x and z are linear with respect to 
each other because the object is planar 
(or linear, in Figure 2), u and x are linear 
with respect to each other for the same 
reason. Well, if x/z is linear in screen 
space, and x is linear with u, then u/z is 
linear in screen space as well (you can 
prove this to yourself by playing around 
with Equations 1, 3, and 5). Instead of 
dividing x/z by 1/z to generate x coordi- 
nates that we then use to solve for u 
coordinates, we can interpolate u/z and 
divide it by 1/z to generate the u values 
directly. 

Affine texture mapping ignores 
these results and linearly interpolates u 
and v in screen space without the divide. 
This results in funky warping, but for 
some polygons it's not too bad (and 



because there's no divide it has the 
potential to be a lot faster). A compari- 
son is beyond the scope of this article, 
but you can find affine texture mappers 
on x2ftp.oulu.fi, which I mentioned pre- 
viously. 

Our Story So Far 

L et's take a break, sum up our results to 
this point, and outline a simple algorithm 
to perspective texture map the line seg- 
ment in Figure 2. 

We've shown that 1/z and u/z are 
linear in screen space, so the algorithm 
for texture mapping Figure 2 goes like 
this: 

• Project the object vertices into screen 
space, giving x' =x/z and u' =u/z. 

• L et z ' = 1/z at each vertex. 

• Linearly interpolate u' and z' between 
x ' and x/, stepping x' by 1 pixel each 
loop. 

• At each pixel x', calculate u by u'/z', 
and use u to fetch the correct texel. 

• W rite the texel to the destination at 
x'. 

T he proofs for y and v are analogous 
to those for x and u, so this is all there is 
to writing a three-dimensional perspec- 
tive texture mapper. 

Interpolation Breakdown 

I n the simplified algorithm I 've outlined, 
we linearly interpolated u' and z' over 
the length of the scanline. Each linear 
interpolation usually involves these steps: 

• Figure out the start and end values of 
the interpolants (in Figure 2, u ',z ' 
and u/.z/, respectively). 
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• C alculate the amount each changes as 
it moves from start to end (U/-U,,' and 

Zi'-O- 

• D ivide the change by the distance over 
which you want to interpolate (X/-X,,') 
to get each step. 

• I ncrement from the start to the end by 
this step. 

T his is a fair amount of work, and if 
we plan to rasterize polygons like the tri- 
angle shown in Figure 3, we have even 
more work to do. W e need to interpolate 
at least 1/z, u/z, and v/z (and possibly 
one or three colors), and if we first calcu- 



Figure 3. Calculating Gradients 




late the interpolants down each edge, and 
then calculate new ones when we get to 
each scanline we will soon get lost in a 
sea of interpolants going in all sorts of 
directions. L uckily, there is a better way. 

It just so happens that the incre- 
ments in each linear interpolant for a sin- 
gle step in x or in y are constant across 
the whole polygon. T his is a very impor- 
tant and very cool result because it means 
we can calculate these increments— called 
the gradients— once and never need to 
worry about calculating interpolants 
again during rasterization. In other 
words, when we want to rasterize a poly- 
gon, we calculate the gradients in x and 
in y for each parameter at the very begin- 
ning, and every time we step in x or y or 
both we just add in the appropriate gra- 
dients. W hen we get to a scanline we 
want to draw, we don't need to calculate 
linear interpolations for all of our para- 
meters as we step across the scanline in x, 
because we already have their gradients 
with respect to x sitting around! In the 
same vein, stepping down an edge is sim- 



ply some combination of the gradient in 
x and the gradient in y. (If you think 
about it, this also means you only need to 
interpolate the parameters down one 
edge. Ponder that one for a while.) 

To show how gradients are calculat- 
ed, let's use the triangle PjPjPj in Figure 
3. E ach vertex has a screen space x and y 
associated with it (x',y'), but in addition 
there is an arbitrary parameter, c', which 
could be color for Gouraud shading or 
1/z, u/z, or v/z for perspective texture 
mapping. It is any parameter we can lin- 
early interpolate over the surface of the 
two-dimensional (screen space) triangle. 

G iven this triangle, let's figure out 
how the parameter c' changes if we hold 
y constant and step in x. W e will use the 
point P 4 in our construction (P 3 and P 4 
are both on the PjP 2 line in Figure 3). It 
is clear that y 4 ' = y„', and we can derive 
the other coordinates for P 4 using the line 
equations: 

x j ~ x 2 _ x 4 ~ x 2 

y{ -yi ~ yA -y% 
and: 

c{ —C'l _ C4' —C2 

y\ -yi ~ y4 -yi 

Substituting y ' for y 4 ' and solving for the 
various coordinates gives us: 

yV = yd 
and: 

C4 ' = [yT^ky y ° : ~^ + C2 ' 

N ext, refer to Figure 5 to compute 
the difference in c' (called dc') as it 
moves from P to P 4 with Equation 6. 

The analog for c' with respect to y 
as we move from P to P 3 is also shown in 
Figure 5, in Equation 7. (Notice the 
denominators: dx =-dy.) 

T he values dc'/dx and dc'/dy are 
called the gradients for the parameter; 
dc'/dx is the gradient with respect to x 
and dc'/dy is the gradient with respect to 



y. W e can calculate the gradients for 1/z, 
u/z, and v/z with respect to both x and y 
at the top of our texture mapper and 
never need to calculate them again during 
the rasterization of this polygon. 

ur new texture mapping algorithm 
lookslikethis: 

• Project the object vertices into screen 
space, giving x', y', u' = u/z, v' = v/z, 
and z' = l/z. 

• Calculate the gradients in x and y for 
u', v', and z'. 

• Linearly interpolate down each edge 
and across each scanline using the gra- 
dients. 

• At each pixel, calculate u by u'/z' and 
v by v'/z', and use u and v to fetch the 
correct texel. 

• W rite the texel to the destination at 

x',y'. 

The only thing we're missing is a 
consistent fill convention to make sure 
we light the correct destination pixels as 
we rasterize the polygon. nee we have a 
fill convention, we can guarantee poly- 
gons will abut properly and we won't 
have any skipped pixels (dropouts) or 
overwrites at the edges. 

Conventional Wisdom 

A fill convention is a set of rules that 
describes how to light pixels in the screen 
under various edge conditions. The first 
step towards implementing a fill conven- 
tion is defining exactly which pixels we 
want lit when a polygon is rasterized. 
F igure 4 shows the raster grid of the dis- 
play, with pixel centers marked with 
black dots. 

We will define what's called a top- 
left fill convention. Top-left refers to the 
tie breaking rule used when the edge of a 
polygon lands exactly on a pixel center; if 
the edge is a top or a left edge, the pixel 
is in the polygon, if it's a right or a bot- 
tom edge, the pixel is considered out. 
You can see this convention in Figure 4. 
If the red edge is shared by the blue and 
the yellow polygon, they will not light 
any of the same pixels. The horizontal 
red edge is the top of the yellow polygon, 
so the pixels are considered members of 
that polygon. In contrast, the horizontal 
red edge is a bottom edge of the blue 
polygon, so the pixels are not lit. All 
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other pixels— those not intersected on 
pixel centers— are lit if they are "strictly 
in" the polygon. I n other words, the pixel 
center must be completely inside the 
edge for the pixel to be lit. I n contrast 
with Figure 4, real edges are infinitely 
thin, so the pixel center is either out, 
intersected exactly, or in. 

T he next step is to define the fill 
convention mathematically. A top-left fill 
convention is defined by the ceiling func- 
tion for the left and top edges, and the 
ceiling-1 of the right and bottom edges. 
(The ceiling function bumps a fractional 
number up to the next integer unless it's 
already an integer, in which case the 
number stays the same.) W ell be step- 
ping in y to generate scanlines, so the 
equation for generating x coordinates 
from y coordinates as we step from P to 
P 2 in Figure 3 is: 




W e apply the ceiling function to 
this equation to give us integer raster val- 
ues for a given y: 




If our starting coordinates are real 
numbers instead of integers, we need to 
apply our convention to the y coordinate 
as well to generate the initial y value: 

Joint' = bo'] 

n a number of scanlines in F igure 
4, the real edge— the line on which we're 
interpolating our parameters— differs 
from the starting pixel center by some 
small amount. Pixels in the display are 
not points, they're actually boxes with an 
area around the pixel center (the pixel 
center is the integer coordinate, and the 
box extends 0.5 pixels to each side), and 
when stepping from pixel to pixel we 
want to make sure we step from one pixel 
center to the next. If we don't step on 
pixel centers, our textures will appear to 
swim as our polygon rotates because we 
aren't sampling from the same place in 



Figure 4. Fill Conventions 
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the pixel each time. Also, when reading 
from what are essentially random places 
in each pixel it's possible to generate tex- 
ture coordinates outside the texture 
bitmap (which could crash our program). 

Find Your Center 

G iven that we want to sample the texture 
from the exact pixel center, we need to 
make sure our interpolants are 
prestepped on each scanline by the differ- 
ence between the real edge and x int . If we 
do this correctly, our texture mapper will 
never read outside the texture (assuming 
the texture coordinates are valid in the 
first place, of course), and our textures 
will not swim as our polygon moves 
around the screen. A Iso, we won't get the 
"hairy texture" artifacts you see in a ras- 



Figure 5. Equations 6 and 7 



terizer that doesn't step on pixel centers, 
where lines in the texture that should be 
straight come out with little notches and 
pimples. 

Figure 6 shows a close-up of a 
group of pixels. To start rasterizing, we 
must first step our edge to the point A. 
This involves an x and y prestep for our 
interpolants, marked with dotted lines. 
N ow, we can precalculate each parame- 
ter's step in y and in x for a single scan- 
line step in the screen using the gradients 
we calculated beforehand, so each time 
we move from one scan to the next, we 
just add each step to its interpolant to 
find the new value. W hen it's time to 
draw a scanline, we must step to the first 
pixel center. F igure 6 shows this step as a 
dotted line at each scanline. 



dd _ £± -cq _ (gi ~ c 2 )(yo -yi ) - (cp -c 2 ' )(y{ -y 2 ' ) 
dx x 4 ' -x ' (xi -x 2 ' )Oo' -yi ) - ( x o ~ x 2 )(yi -y-i ) 



(6) 



dd _ ~ c o' _ ( c l ~ c 2 )( X Q ~ x 2 ) ~ ( c o' ~ c 2 )( x \ ~ x 2 ) 

dy ~ y$ -yo ~ C*o' ~ x i )W -yi ) - W -x 2 ' )(yd -yi ) 



(7) 
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All this prestepping probably sounds 
expensive, but there is a way to do it that 
requires no extra multiplies per scanline. 
We'll discuss this in more detail next 
month. 

Summary and 
Random Notes 

This article is too long already, but 
there's still plenty we haven't discussed. 

First, we didn't talk about all the 
special cases where linearly interpolating 
the texture coordinates actually is correct, 
like walls and floors. A close examination 
of the math above will show you why this 
is true (hint: look at the gradients for the 
1/z term). Games like Doom use this to 
speed up their texture mappers at the 
expense of not allowing arbitrarily orient- 
ed polygons. There's lots of information 
covering these techniques on the I nternet. 

W e also didn't discuss antialiasing 
or homogeneous coordinate systems. 
D igital ImageWarping is a great resource 
for antialiasing and image resampling, 
while Foley and van Dam cover homoge- 
neous coordinates. 

Even considering what we missed, 
we certainly covered a lot of material in a 
small space, and I encourage you to 
reread this article with a piece of paper in 
hand and try to prove the various results 
for yourself. 

The sample code included with this 
article implements the perspective texture 
mapping algorithm. It is a high quality 
implementation with one small problem: 
it's a bit slow, doing a divide and two mul- 
tiplies per pixel. In the next column I'll 
show how to optimize this code, which 
will give you a production quality perspec- 
tive texture mapper you can just plop right 
in your game engine. ■ 



Chris H ecker wishes he had a Ph.D . in 
mathematics so he didn't have to struggle 
with the derivation of the equation for the 
area of a trianglew henever hewanted touse 
it. I n the meantime, he can be reached at 
checker§bix.com or through Game Devel- 
oper magazine. 



Figure 6. Pixel Centers 
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Listing 1. Perspective Texture Mapper 



#include<windows . h> 
#include<math.h> 

struct P0INT3D { 
float X, V, Z; 
float U, V; 

}; 

•oid TextureMapTriangle( BITMAPIN FO const *pDestInfo, 
BYTE *pOestBits, P0INT3D const *pVertices, 
BTJMAPINFO const *pTextureInfo, 
BYTE *pTextureBits ); 

structures, inlines, and function declarations 

struct gradients { 

gradientst P0INT3D const tpVertices ); 

float a0ne0verZ[3] ; // 1/z for each vertex 

float aU0verZ[3]; // u/z for each vertex 

float aV0verZ[3]; // v/z for each vertex 

float dOneOverZdX, dOnedverZdY; // d(l/z)/dX, d(l/z)/dY 

float dUOverZdX, dUOverZdY; // d(u/z)/dX, d(u/z)/dY 

float dVOverZdX, dVDverZdY; // d(v/z)/dX, d(v/z)/dY 

}; 

struct edge { 

edgetgradients const ([Gradients, 

P0INT3D const *pVertices, 

int Top, int Bottom ); 
inline int Step( void ); 



float X, XStep; // fractional x and dX/dY 

int Y, Height; // current y and vert count 



float OneOverZ, OneOverZStep; // 1/z and step 

float UOverZ, UOverZStep; // u/z and step 

float VOverZ, VOverZStep; // v/z and step 

}; 

inline int edge::Step( void ) { 
X += XStep; Y++; Height-; 
UOverZ += UOverZStep; VOverZ += VOverZStep; 
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Listing 1. Perspective Texture Mapper (Continued on p. 25) 



pLef t, pRight, pTextureInfo,pTextureBits); 
TopToMiddle.StepO ; TopToBottom.StepO ; 



Height = MiddleToBottom. Height; 

if(MiddlelsLeft) { 

pLeft = JiMiddleToBottom; pRight = (iTopToBottom; 
} else { 

pLeft = STopToBottom; pRight = SMiddleToBottom; 

} 

while(Height-) { 

DrawScanLine(pDestInfo,pDestBits, Gradients, 
pLef t, pRight, pTextureInfo,pTextureBits); 
MiddleToBottom . Step ( ) ; TopToBottom . Step ( ) ; 

} 



/********** gradients constructor **********/ 

gradients: :gradients( P0INT30 const *pl/ertices ) 
{ 

int Counter; 

float OneOverdX = 1 /(((pVertices[l].X - pVertices[2] .X) * 
(pVertices[0].V - pVertices[2] .V)) 
((pVertices[0].X - pVertices[2] .X) 
(pVertices[l].Y - pVertices[2] .V))) 

float OneOverdY = -OneOverdX; 

for(Counter = OjCounter < 3;Counter++) { 

float const OneOverZ = l/pVertices[Counter] .Z; 
aOneOverZ [Counter] = OneOverZ; 
aUOverZ [Counter] = pl/ertices [Counter] .U * OneOverZ; 
aVOverZ[Counter] = pl/ertices [Counter] .V * OneOverZ; 

} 

dOneOverZdX = OneOverdX * (((aOneOverZ[l] - a0ne0verZ[2]) 
(pVertices[0].Y - pVertices[2] .Y)) - 
((a0ne0verZ[0] - a0ne0verZ[2]) * 
(pVertices[l].Y - pVertices[2].Y))); 
dOneOverZdY = OneOverdY * (((aOneOverZ[l] - a0ne0verZ[2]) 
(pVertices[0].X - pVertices[2] .X)) - 
((a0ne0verZ[0] - a0ne0verZ[2]) * 
(pVertices[l].X - pVertices[2].X))); 

dUOverZdX = OneOverdX * (((allOverZCt] - aU0verZ[2]) 
(p¥ertices[0].Y - pVertices[2] .Y)) - 
((aUOverZM - aUDverZ[2]) * 
(p¥ertices[l].Y - pVertices[2].Y))); 
dUOverZdY = OneOverdY * (((aU0verZ[l] - aU0verZ[2]) 
(p¥ertices[0].X - pVertices[2] .X)) - 
((aUOverZM - aU0verZ[2]) * 
(p«ertices[l].X - pVertices[2].X))); 

dVOverZdX = OneOverdX * (((aVOverZtl] - aV0verZ[2]) 
(pVertices[0].Y - pVertices[2] .Y)) - 
((aV0verZ[0] - aV0verZ[2]) * 
(pVertices[l].Y - pVertices[2].Y))); 
dVOverZdY = OneOverdY * (((aVOverZtl] - aV0verZ[2]) 
(pVertices[0].X - pVertices[2] .X)) - 
((aV0verZ[0] - aV0verZ[2]) * 
(pVertices[l].X - pVertices[2].X))); 



/********** edge constructor ***********/ 

edge::edge( gradients const ftGradients, 

P0INT3D const *pVertices, int Top, int Bottom ) 

{ 

Y = ceil(pVertices[Top].Y); 
int YEnd = ceil(pVertices[Bottom].Y); 



} 



OneOverZ += OneOverZStep; 
return Height; 




void DrauScanLine( BITMftPINFO const *pDestInfo, 
BYTE *pDestBits, gradients const ftGradients, 
edge *pLeft, edge *pRight, 

BTTMAPINFO const *pTexture!nfo, BYTE *pTextureBits ); 



/****«.** TextureNapTriangle 



v 




void TextureNapTrianglet BTTNAPINFO const *pDestInfo, 
BYTE *pDestBits, P0INT3D const *pVertices, 
BTTMAPINFO const *pTextureInfo, 
BYTE *pTextureBits ) 

int Top, Middle, Bottom; 
int HiddleCompare, BottomCompare; 
float YO = p«ertices[0].Y; 
float Yl = pvertices[l].Y; 
float Y2 = pVertices[2].Y; 



// sort vertices in y 
if(YO < Yl) { 
if(Y2 < YO) { 

Top = 2; Middle 
MiddleCompare = 
} else { 
Top = 0; 
if(Yl < Y2) { 
Middle = 1; 
MiddleCompa 
} else { 

Niddle = 2 
MiddleCompa 

} 

} 

} else { 

if(Y2 < Yl) { 

Top = 2; Middle 
MiddleCompare = 
} else { 
Top = 1; 
if(YO < Y2) { 
Middle = 0; 
MiddleCompa 
} else { 

Middle = 2 
MiddleCompa 

} 



= 0; Bottom = 1; 

0; BottomCompare = 1; 



Bottom = 2; 
re = 1; BottomCompare = 2; 

Bottom = 1; 

re = 2; BottomCompare = 1; 



= 1; Bottom = 0; 

1; BottomCompare = 0; 



Bottom = 2; 

re = 3; BottomCompare = 2; 
Bottom = 0; 

re = 2; BottomCompare = 3; 



gradients Gradients(pVertices); 
edge TopToBottom(Gradients,pVertices, Top, Bottom) ; 
edge TopToMiddle(Gradients,pVertices, Top, Middle) ; 
edge MiddleToBottom(Gradients,pVertices, Middle, Bottom); 

pLeft, *pRight; 
int MiddlelsLeft; 

// the triangle is clockwise, so 
//if bottom > middle then middle is right 
if (BottomCompare > MiddleCompare) { 
MiddlelsLeft = 0; 

pLeft = STopToBottom; pRight = STopToMiddle; 
} else { 

MiddlelsLeft = 1; 

pLeft = STopToMiddle; pRight = STopToBottom; 

} 

int Height = TopToMiddle. Height; 

while(Height-) { 

DrawScanLine(pDestInf o , pDestBits , Gradients , 
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Listing 1. Continued from p. 22 



Height = YEnd - Y; 

float YPrestep = Y - pVertices[Top] .Y; 

float RealHeight = pVertices [Bottom] .Y - pVertices[Top] .Y; 
float RealWidth = pVertices [Bottom] J - pVertices [Top] .X; 

X = ((RealWidth * YPrestepJ/RealHeight) + pVertices [Top] .X; 

XStep = RealWidth/RealHeight; 

float XPrestep = X - pVertices [Top] .X; 

OneOverZ = Gradients. aOneOverZ[Top] + 

YPrestep * Gradients. dOneOverZdY + 

XPrestep * Gradients. dOneOverZdX; 
OneOverZStep = XStep * 

Gradients. dOneOverZdX + Gradients. dOneOverZdY; 

UOverZ = Gradients. aU0«erZ[Top] + 

YPrestep * Gradients. dUDverZdY + 

XPrestep * Gradients. dUDverZdX; 
UOverZStep = XStep * 

Gradients. dUDverZdX * Gradients. dUDverZdY; 

VOverZ = Gradients. aV0«erZ[Top] + 

YPrestep * Gradients. dVDverZdY + 

XPrestep * Gradients. dVDverZdX; 
VOverZStep = XStep * 

Gradients. dVDverZdX * Gradients. dVOverZdY; 



/********** DrawScanLine ♦***********/ 

void DrawScanLine( BITMflPINFO const *pDestInfo, 

BYTE *pDestBits, gradients const ftGradients 
edge *pLeft, edge *pRight, 
BITWAPINFO const *pTextureInfo, 
BYTE tpTextureBits ) 



// we assume dest and texture are top-down 

int DestWidthBytes = 

(pDestInfo->bmiHeader.biWidth + 3) ft "3; 
int TextureWidthBytes = 

(pTextureInfo->bmiHeader.biWidth + 3) ft "3; 

int XStart = ceil(pLeft->X); 
float XPrestep = XStart - pLeft->X; 



pDestBits += pLeft->Y * DestWidthBytes + XStart; 
int Width = ceil(pRight->X) - XStart; 

float OneOverZ = pLeft->0ne0verZ + 

XPrestep * Gradients. dOneOverZdX; 

float UOverZ = pLeft->UOverZ + 

XPrestep * Gradients. dUDverZdX; 

float VOverZ = pLeft->VDverZ + 

XPrestep * Gradients. dVDverZdX; 

iftlfidth > 0) { 
while(Width-) { 

float Z = 1/OneOverZ; 
int U = UOverZ * Z; 
int V = VOverZ * Z; 

*(pDestBits++) = *(pTextureBits + U + 
(V * TextureWidthBytes)); 

OneOverZ += Gradients. dOneOverZdX; 
UOverZ += Gradients. dUDverZdX; 
VOverZ += Gradients. dVDverZdX; 
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DIGITIZED SOUND 



Programming 
Digitized Sound 
On the Sound Bl 



aster 



Figure 1. Comparing Analog and Digitized Waves 




In the early days of PC sound, we had 
the PC speaker and its lesser-known 
sidekick, the Programmable Interval 
Timer (PIT). You could program 
the frequency of this hardware timer, 
and hook the timer up to the speak- 
er. By changing this frequency, you 
could produce a surprising variety of 
sound effects and music. 

There was only one problem- 
gamers and programmers hated it. So the 
world moved onto generation two: the 
AdLib FM Synthesizer. You could pro- 
gram it to produce decent music and even 
certain sound effects. 

There was still a problem. The 
sound effects stunk. 

Along came the Sound Blaster. It 
combined a digital-to-analog converter 
(DAC) with an FM synthesizer. Now, 
game programmers had access to decent 
music and decent sound effects. Finally. 

There was much rejoicing. Until the 
question arose as to how to program the 
thing. 

In developing D iamondW are's 
Sound ToolKit, we discovered scarce and 



poorly written documentation on the 
Sound Blaster. In this article, we'll give 
you the information you need to start 
developing your own digitized sound 
code. 

Theory of Digitized Sound 

As with most areas of computer program- 
ming, it is good to know some general 
background theory. I t's often the case that 
the "easy" pitfalls are far from obvious. 
W ith sound, there are a number of possi- 
ble problems that will cause audible 
glitches. 

W hen digitized sounds are produced 
from an analog source, signals travel 
down an interconnect cable, go through a 
preamplifier, and are eventually processed 
by an analog to digital converter. We 
mention this because each step will have 
an effect on sound quality and overall vol- 
ume. 

Figure 1 shows the difference 
between continuous (analog) and discrete 
(digitized) waves. Unlike analog waves, 
digitized sounds are quantized, meaning 
that the amplitude at each point can have 
only one of a finite number of values. In 
addition, the sounds are discretely sam- 
pled; that is, the value is sampled periodi- 
cally. Both facts raise important consider- 
ations. W ell discuss the amplitude prob- 
lem first, then thetime problem. 

T he range of values for each sample 
is finite. In a typical game playback sys- 
tem, this is 8 bits, or -128 to +127. The 
softest sound that can be represented is 
£L, and any sound softer than this thresh- 
old will be lost at 0. T he loudest sound is 
about £1.27. A ny sound louder than this is 
clipped, producing a harsh and nasty 
noise. 
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W hen you're mixing two or more 
sounds together, this clipping limit 
applies to the total mix. Thus, you want 
to produce your sounds at low volume 
levels so you can mix several of them 
without problems. If you are stuck with 
preproduced sounds, there are two ways 
to cut their dynamic range. The first is 
straightforward— you divide each sample 
by a constant. T his is often implemented 
as a shift- right operation. It's fast and 
easy, but if you divide too much you will 
lose the softer parts of your sounds. 

The other method is to dynamically 
compress your sounds. Basically, this will 
soften the louder parts and raise the softer 
parts. T his is what pop radio stations do. 
After this process, the entire sound is 
equally loud. The implementation of this 



is beyond the scope of this article, but we 
mention it here for completeness. Quality 
sound processing software has the ability 
to compress dynamic range. 

A digitized sound is considered a 
discretely sampled waveform because it is 
not contiguous in the time domain. In 
other words, you're sampling the wave- 
form at T=l and T=2 but there's no 
information for T=1.5. When it's played 
back, there's obviously sound at every 
moment— even in between the sample 
points, which isthecrux of the problem. 

To understand this dilemma, let's 
look at analog waveforms. It turns out 
that every possible analog waveform can 
be represented by the sum of a finite 
number of pure sine waves. 

The plot of a sound on an osci Mo- 



Figure 2. Wave and Spectrum/Pulse and Spectrum 
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scope is a time-domain plot, as shown in 
Figure 2a. That is, while the Y-axis repre- 
sents amplitude, the X-axis represents 
time. I t's possible to transform a wave into 
the frequency-domain. A plot after such a 
transformation, shown in Figure 2b, uses 
the X-axis to represent frequencies; each 
point farther to the right would be a high- 
er frequency. You could read the graph to 
determine, for example, how loud the 
IK H z component is. The highest fre- 
quency sine wave in this series is no higher 
than the highest frequency in the original 
wave. Figure 2c illustrates a square-wave 
pulse, comprising an infinite frequency of 
components, as you can see in its frequen- 
cy-domain plot, shown in Figure 2d. 

N ow, let's get back to digital sound. 
It turns out that to "capture" a given fre- 
quency, you need to sample the wave at a 
rate at least twice as high as that frequen- 
cy. For example, if you had a sound at 
1KH z, you should sample it at 2KH z or 
higher. This is known as the N yquist rate. 

Figure 3 demonstrates the effects of 
sampling a wave above and below the 



N yquist rate. In Figure 3a, we see the 
original analog wave and its spectrum in 
the frequency domain. If this signal is 
sampled above the N yquist rate, as shown 
in Figure 3b, it can be correctly recon- 
structed. If the signal is sampled below the 
N yquist rate, as shown in Figure 3c, there 
is not enough information to properly 
reconstruct the wave and aliasing occurs. 

H ow can we capture a sine wave with 
only two points per cycle? W e know in 
advance that it is a sine wave. T here's only 
one possible sine wave that can be formu- 
lated, given two points during each cycle. 
Any waveform can be broken down into 
sine waves, so we have a way of discretely 
capturing (digitizing) analog sounds 

There's one last issue we must 
cover— playback. Because the waves are 
discretely sampled and are represented by 
few points, they're going to look quite 
square, as shown in Figure 4. Square look- 
ing digital signals connote "high frequen- 
cy." If you play them back as is, they're 
going to have lots of noise— in fact, you'll 
hear a complete harmonic overtone of 



Figure 3. Sampling Rates and Aliasing 





your sample. This lends a nasty metallic 
sound. T he solution is to filter the output 
of the D AC in analog, eliminating all fre- 
quencies above half the sampling rate. 

The Sound Blaster Family 

We've seen 10 models of Sound Blaster 
from C reative Labs and dozens of clones 
from third parties. Fortunately, they all 
share the common architecture first pre- 
sented in the Sound Blaster 1.5. By far, 
the Sound Blaster 16, Sound Blaster 
PRO 2, and Sound Blaster 2.1 sold the 
most units, and they're still selling today. 

T his article will focus on the Sound 
Blaster 1.5, because it's the lowest com- 
mon denominator. T he higher models all 
support the Sound Blaster 1.5's modes. 

Detecting the Sound Blaster 

You can find the Sound Blaster by parsing 
the BLASTER environment variable. It's the 
easiest method, and it's recommended by 
Creative Labs and other manufacturers, 
especially because it can't crash the user's 
machine. T his is how we'll do it here. 

The BLASTER environment variable 
comprises several sections. A typical 
BLASTER variable might look like this: 

BLASTER=A220 15 Dl H5 P330 M250 T6 

where: 

• A is the base port address (here, it's 
220h) . V al ues may be 210h to 280h. 

• I is the IRQ (interrupt request) level. 
Values may be 2, 3, 5, 7, or 10. 

• D is the 8-bit DM A channel. Values 
may be 0, 1, or 3. 

• H, if present, is the 16- bit DM A chan- 
nel. Values may be 5, 6, or 7. 

• P, if present, is the port for MPU401, 
either 300h or 330h. 

• T is the type of Sound Blaster card. 

You can program the Sound Blaster 
in 14 easy steps: 

• Reset the DSP (digital signal proces- 
sor) and put it into a known state. 

• Set up your interrupt service routine 
(ISR). 

• Enable the IRQ the Sound Blaster 
card is using. 

• Program the D AC speaker. 

• Program the D M A controller for a 
single cycle transfer. 
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Figure 4. Comparing a Digitized Wave to the Original Analog Wave 




• Program the playback rate (time con- 
stant). 

• Program the DSP output/input for 
single- cycle transfer. 

Transfer begins immediately after 
step 7. At this point, you can go draw 
some graphics, read a disk, and get some 
coffee. W hen the buffer is done, the 
Sound Blaster will generate an interrupt. 
Thiswill transfer control to thelSR. 

Next: 

• Acknowledge the DSP. 

• Send the programmable interrupt con- 
troller (PIC) an end of interrupt 
(EOI). 

• Program the Sound Blaster to play 
another buffer or set a flag to show 
that we are done playing. 

After we have finished all data trans- 
fers, we need to: 

• D isablethe DAC speaker. 

• Disable the IRQ. 

• Unhook the I SR. 

• Reset the Sound Blaster DSP, leaving 
it in a good state, ready to work with 
other applications. 

Detect and Reset 

Before we assume that the presence of the 
BLASTER variable means we have a Sound 
Blaster in the system, we can check to see 
if a D SP really does exist at the specified 
port, shown in Table 1, and attempt to 
send it a reset by doing the following: 

• W rite a 1 to the sb.RESET port. 

• Wait three microseconds (/xsec). 

• Write a to sb.RESET. 

• Read sb.READ.STATUS (up to 65,535 
times), waiting for the msb (most sig- 
nificant bit) to beset. 

• If the msb never gets set, no Sound 



Table 1. Sound Blaster DSP Ports 



>■ 

t 



Original wave 

Blaster card is present. 

• Read sb_READ_DATA. If the return value 
isAAh, a Sound Blaster card is present. 

• If the return value is not A Ah, repeat 
Steps 4 to 6 until the count runs out, 
or a Sound Blaster card is found. 

Reading and Writing 

To read data from the DSP, we must 
read from sb.READ.STATUS until the msb is 
set. T hen, read from sb.READ.DATA: 

unsigned sb_ReadDSP( unsigned baseport) 
uhile(!(0x80 & inp(baseport + 
sb.READ.STATUS))); //waiting for the 
//MSB to be set 
return((unsigned)inp(baseport + 
sb.READ.DATA)); 

} 

T o write to the D SP , read from 
sb.COHMAND.STATUS until the msb is reset. 
Then, write the desired command (or 
command data) to sb.WRTTE.COMMAND: 

void sb_WriteDSP(unsigned baseport, 
unsigned value) { 
uhile(0x80 & inp 
(baseport +sb.WRITE.STATUS)); 













t 



Digitized wave 
// uait for the USB to be clear 

} 

outp(baseport + sb.WRITE.COMMAND, 
(int) value); 

} 

Handling DSP Interrupts 

T he D SP will generate an interrupt when 
ever it's done recording or playing a 
DMA buffer. To keep the system from 
crashing and the Sound Blaster playing, 
we need to set up an I SR. Each interrupt 
must be acknowledged by reading 
sb.ACKlRQ. T his tells the D SP that you 
have received the interrupt, and it can 
stop pulling theline. 

Using DSP commands 

A DSP revision of l.xx accepts 20 com- 
mands, as shown in Table 2. We will only 
need to use five commands to get up and 
running. To simplify the following dis- 
cussion, we will use the example functions 
sb.ReadDSP and sb.WriteDSP. 

The DAC speaker controls what we 
hear (and what the Sound Blaster hears). 
W ith the speaker on, we can hear the 
digitized playback, but the Sound Blaster 
can't hear us (record), and vice versa. 

To turn on the speaker, send sb.DAC- 
SPKRON to the DSP and wait 112 /xsec for 
the DSP to complete the operation: 

sb_WriteDSP(baseport, sb.DACSPKRON) ; 

Turning the speaker off is similar; 
send sb.DACSPKROFF to the DSP and wait 
even longer (220 /usee)— no one said this 
hardware was fast: 

sb_WriteDSP(baseport, sb.DACSPKROFF) ; 
The sb.SETTlMECONST command sets 



Port Number 



Write 



Read 



During IRQ 



2X6h 
2XAh 
2XCh 
2XEh 



sb.RESET 
None 

sb.WRTTE.COMMAND 
None 



None 

sb.READ.DATA 

sb.WRITE.STATUS 

sb.READ.STATUS 



Normal 
Normal 
Normal 

sb.ACKIRp (read-only) 



x denotes base address. For base address of 220h, the ports are 226h, 22Ah, 22Ch, and 

22Eh. 
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Table 2. DSP.l xx Commands 



Number Description 

lOh Set polled output mode and PCM (uncompressed) samples. 

14h Set DMA output mode and PCM samples. 

74h Set DMA output mode and 8- to 4-bit ADPCM samples. 

75h Set DMA output mode and 8- to 4-bit ADPCM samples 

(with reference byte). 

76h Set DMA output mode and 8- to 3-bit ADPCM samples. 

77h Set DMA output mode and 8- to 3-bit ADPCM samples 

(with reference byte). 

16h Set DMA output mode and 8- to 2-bit ADPCM samples. 

17h Set DM A output mode and 8- to 2-bit ADPCM samples 

(with reference byte). 

38h Set polled output mode and M ID I data. 

20h Set polled input ode and PCM (uncompressed) samples. 

24h Set DMA input mode and PCM (uncompressed) samples. 

30h Set polled input mode and M ID I data. 

31h S et interrupt input mode and M IDI data. 

DOh Pause DMA. 

D4h Resume DMA. 

40h Set time constant 

80h Pause DMA for a specified duration. 

Elh Get DSP version. 

Dlh Enable DAC speaker. 

D3h Disable DAC speaker. 



how many samples per second the DSP 
will record or playback, but it doesn't take 
a sampling rate directly. W e must convert 
from H z to the Sound Blaster time con- 
stant. The time constant is always an 
unsigned byte: 

tc = 256 - (1000000 / (num_channels * 
sampling.rate)) ; 

sb.WriteDSP(baseport, sb.SETTTMECONST) ; 
sb_WriteDSP(baseport, rate); 

T o play a sound, send the D SP one 
of the output sound commands. W ell use 
sb_PLA Y8BITHQN0. Follow this command 
with 2 bytes representing the size of the 
buffer. T he buffer can be between 1 and 
65,536 bytes. N o one would want to pro- 
gram the Sound Blaster to transfer 
bytes, so means 1 byte, and 65,535 
means 65,536 bytes: 

loubyte = (unsigned char) (buff size - 1); 
highbyte = (unsigned char) ((buff size - 1) 
» 8)); 

sb.WriteDSP(baseport, sb_PLAY8BTJM0N0) ; 
sb_WriteDSP(baseport, loubyte); 
sb_WriteDSP(baseport, highbyte); 



Interrupt Programming 

N o discussion of Sound Blaster DSP pro- 
gramming would be complete without 
mention of the 8259A PIC. Integrally 
related is the 80x86 processor's interrupt 
mechanism, including the vector table. 
Let's go over the steps involved in an IRQ 
and its handling. 

The Sound Blaster must go through 
nine steps to build an IRQ: 

• The Sound Blaster DSP signals the 
PIC that it wants to interrupt the 
CPU. 

• The PIC checks the interrupt mask 
register (I M R ) to see if this is cool. 

• If so, the PIC checks to see if any high- 
er-priority I RQ 's are being serviced. 

• If so, it waits until they send an end of 
interrupt (EOI) tothePIC. 

• If not, the PIC sends a signal to the 
C PU over a dedicated line. 

• If the interrupt flag is set, the CPU 
replies with an interrupt acknowledge 
(INTA). 

• The PIC then sends an IRQ and the 
IRQ level. 

• The CPU pushestheflags.CS, and 
IP registers— in that order— on the 



current stack 

• T he C PU jumps to the address speci- 
fied in the vector table for this IRQ. 

To respond to an IRQ (for ISR's 
only): 

• Tell the hardware (the Sound Blaster 
D SP) to stop pulling the interrupt line. 

• Send an EOI tothePIC. 

• Set a global variable— a flag— for main 
program loop (this step is optional). 

• Prepare the next sound buffer. 

• Return from interrupt (I RET instruc- 
tion). 

There's a simple INT 21 (DOS) call 
to hook the interrupt vector, which is 
even easier in C . W e also need to enable 
our interrupt in the PIC itself. To do this, 
read the IM R, reset the bit corresponding 
to the IRQ level to which the Sound 
BlasterDSP is set, and write thelM R: 

#define dig.IMRPORT 0x21 
temp = inp(dig.IMRPORT) ; //Read the IHR 
temp k= dig_onmask[irqlevel] ; 
//Enableour channel 

outp(dig_IHRPQRT, temp); //Write the IHR 

Programming the 
DMA Controller 

The 8237A high-performance program- 
mable direct memory access (DMA) con- 
troller provides a way to transfer data 
between memory and the I/O bus without 
using CPU. If you program it properly, it 
allows for easy and nearly overhead-free 
data transfers. M ake a mistake, however, 
and you've as good as sent a garbage truck 
to dump a pile of trash in memory! 

An AT-class machine has two 
DMA controllers and eight DMA chan- 
nels. The DM A controllers have 44 I/O 
ports and four modes of operation. 

W e'll only discuss channels 0, 1, and 
3 (2 is used by the floppy controller). 
These are the 8- bit channels. C hannels 4 
to 7 are 16- bit channels and aren't used 
by 8- bit Sound Blasters 

We're interested in single-cycle 
DMA mode, which means one byte is 
transferred by the D M A controller for 
each data request (DREQ) it receives 
from the Sound B laster DSP. 

There are nine steps to program- 
ming a D M A controller. Steps 2 through 
8 employ either shared registers— used for 
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all channels— or channel specific registers: 

• D i sable interrupts. 

• D isable our D M A channel (shared 
register). 

• Reset the flip-flop (shared register). 

• Set our channel's mode (channel-spe- 
cific register). 

• Program the address register (channel- 
specific register). 

• Program the page register (channel- 
specific register). 

• Program the count register with one 
less than the actual transfer count 
(channel -specific register). 

• Enable the DMA channel (shared 
register). 

• Enable interrupts 

The DM A controller works with 
physical addresses, not with segment off- 
set addresses, not with selectors, and so 
on. In real mode, it's easy to translate 
from segment: offset to a physical address 
(protected- mode selectors can be trans- 
lated as well). T he D M A controller 
works with a page number, which is liter- 
ally the physical address divided by 
65,536. A D M A buffer cannot cross such 
a physical page address; you must verify 
that your buffer meets this criterion! 
W ithin the physical page, the D M A 
controller increments an offset. Code to 
translate from segment: offset to physical 
page and offset is: 

off = (*((unsigned _far *)&(sound))); 
seg = (*((unsigned Jar *)&(sound) + 1)); 
seg «= 4; 

padd = seg + off; // calc physical 
address 

page = padd » 16; // calc page number 

Don't be put off by our method of 
obtaining the segment and offset of a 
pointer. This may seem complex, but 
we're simply taking a pointer to sound; 
the first word this points to is the offset, 
and the second is the segment. 

Explanations of the workings of the 
DMA controller tend to be very lengthy. 
Fortunately, the D M A controller is very 
well documented. W e refer you to two 
books that provide in-depth explanations 
for further reading: Developer Kit for 
Sound Blaster Series, 2nd Ed. (Creative 
Labs, 1993); and The Indispensable PC 



Hardware Book (Addison-W esley, 1993), 
by H ans- Peter M essmer. 

The Code 

T he code that accompanies this article 
compiles with M icrosoft C/C++ 7, Bor- 
land C/C++ 3.1 and 4.0. It should port 
easily to other DOS C environments. 
W e used the large memory model when 
we compiled it. W e tested it with a 
Sound Blaster 1.5, 2.1, Pro 2, 16, and 
AW E32. The code is available on Com- 
puServe in the SD FO RU M in the 
GDM ag Library. ■ 

Keith Weiner and E rik Lorenzen have 
developed a sound toolkit for DOS games, 
called D iamondWare's Sound ToolKit 
(available from MVP Software). Contact 
them via e-mail at keith@dw.com or 
erik@dw.com. 



T H 


E GLOSSARY 


■ ■ orking with the Sound Blaster 
I 1 can require a graduate degree 

IAI t ' ie ' an 9 ua 9 e °f acronyms, 
uU Hence, we provide here a 

■ 1 breakdown of the abbrevia- 
tions used throughout this article. 


ECU 


End of interrupt 


DAC 


Digital-to-analog 
converter 


DMA 


Direct memory 
access 


DREQ 


Data request 


DSP 


Digital signal 
processor 


IMR 


Interrupt 
mask register 


INTA 


Interrupt 
acknowledge 


IRQ 


Interrupt request 


ISR 


Interrupt service 
routine 


PIC 


Programmable 
interrupt controller 


PIT 


Programmable 
interval timer 



32 GAM E DEVELOPER • APRIL/ MAY 1995 



SUPERCHARGE YOUR SPRITES 



Superc harge 
Your Sprites 



Hs we continue on our quest for 
the fastest graphics perfor- 
mance possible, we are going 
to focus on drawing sprites. 
Just what is a sprite? A sprite 
is usually defined as a graphi- 
cal image that moves inde- 
pendently on the screen. 
Characters in video games are sprites. 
So are bullets, explosions— even the cur- 
sor is a type of sprite. 

U nlike tiles or text, sprites often 
come in irregular shapes and sizes. 
These varied shapes often make it diffi- 
cult to optimize a general-purpose 
drawing routine. To achieve superior 
performance when drawing sprites, we 
are going to examine a technique called 
"compiled sprites," sometimes referred 
to as "compiled bitmaps." 

Normal Sprites 

To start, we need to understand how 
sprites are usually implemented. Today, 
most sprites are drawn by a programmer 
or artist using a paint program or some 
form of sprite editor, which itself is a 
custom paint program. The program 
draws the image in a rectangular work 
area, using a palette of colors. 

W hen you begin a new sprite, the 
work area is filled with a color, usually 
black, white, or grey, that you've desig- 
nated as a "transparent" or background 
color. The actual color doesn't mat- 
ter— it's simply a value that the pro- 
grammer decides will be used to indi- 
cate transparency. 

W hen the sprite is drawn by the 
program, only the portions of the image 
block that are not the transparent color 
are actually drawn. The areas with the 



transparent color are left alone, and the 
background shows through. 

Because irregular shapes are so dif- 
ficult to code for, you would usually 
choose to store a sprite in memory as a 
rectangular array of pixels. A normal 
sprite drawing routine then goes 
through the following steps. First, it 
computes the screen address that corre- 
sponds to the upper left pixel in the 
sprite's array, even if the pixel is trans- 
parent. Then it scans the sprite's data 
from left to right and top to bottom, 
checking each pixel to see if it is trans- 
parent. If it is not, the program draws 
that pixel to the screen at an offset cor- 
responding to that pixel's position in the 
sprite's data array. 

T his method works very well and 
you can optimize it with assembly lan- 
guage. But it is not as fast as routines 
that draw solid blocks or tiles, like the 
ones I presented in "Faster Image 
Drawing" (Feb./M ar. 1995). And the 
worst part is that it is slower than these 
routines despite the fact that fewer pix- 
els are actually drawn. T his wouldn't be 
a big deal if we didn't use sprites very 
much, but for many action-oriented 
games, we use them extensively. 

I magine you are writing a Super 
G alaxi an -style game. The player's ship, 
shields, and every bullet, missile, explo- 
sion, and enemy ship is an irregularly 
shaped sprite. You will have to redraw 
every object for each frame of gameplay. 
If your sprite drawing routines aren't 
very good, the game is going to bog 
down when the action gets fast and 
furious. N ow it becomes obvious why 
you want the fastest sprites possible. 

Performance is lost when you draw 
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irregularly shaped sprites not because 
the code is inefficient, but because for 
every pixel, a decision must be made 
whether or not it should be actually 
drawn. In sprite-drawing routines, it 
turns out that not drawing a pixel usual- 
ly imposes a big performance hit on 
normally tight assembly language code. 
This happens because the CPU has to 
jump, flush its prefetch queue, and 
reload it. The code could be reversed, 
but the performance would suffer every 
time a pixel is drawn. You must take 
one of two paths because there is no way 
around the fact that a decision must be 
made. r is there? 

Looking Back, 
Looking Forward 

It the earliest days of 8- bit computers, a 
game would often have dedicated code 
to draw individual sprites. Some systems 
even had hardware support for sprite 
graphics. (H ere's a historical trivia fact: 
The Atari 2600 game system only had 
128 bytes of RAM , so each line of each 
sprite had to be drawn with custom code 
in ROM .) 

Programmers would hand-code 
routines to draw each line, box, and 
pixel that made up a sprite. T he advan- 
tage was that only the pixels that needed 
to be drawn were coded. The biggest 
drawback was that it was a slow process, 
requiring the programmer to change 
code every time one single bit in a sprite 
was changed, possibly introducing bugs 
each time. As graphics got bigger and 
changed more frequently during devel- 
opment, this method proved less practi- 
cal and general purpose routines took 
over. 



But what if the computer could 
automatically generate code that draws 
each sprite, knowing exactly what to 
draw and what to eliminate for each 
image? All the comparisons, branching, 
and other decision-making code that 
would normally be executed every time 
the sprite was drawn or moved would be 
eliminated. The processing time saved 
for every sprite in every frame drawn 
would add up quickly. That is the basic 
premise behind compiled sprites. 

Compiled Sprites 

There are two main categories of com- 
piled sprites. One is what I call "data 
compiled," which converts the sprite 
image into a stream of data that isfed to 
a special routine. All the calculations, 
comparisons, and decisions are made by 
the compiling routine during the com- 
piling process and encoded into the data 
stream. 

T he drawing routine itself is a sim- 
ple state machine that reads each chunk 
of data and processes it in exactly the 
same way. T he inner loops are unrolled 
and contain no comparisons or branches 
to slow things down. The data stream 
provides all the information needed. 
This technique provides a significant 
performance increase and is often used 
with larger or compressed graphic 
images. 

The second category consists of 
what I call "code compiled" sprites. T he 
program generates actual machine lan- 
guage instructions that draw the specific 
image on the screen. There are no deci- 
sion or control instructions, only direct 
writes to video memory. This method 
provides additional performance gains 



Matt Pritc hard 



Sprites come in all 
shapes, sizes, and 
colors. This variance 
often presents per- 
formance challenges 
for developers. Here 
are some lips to help 
p achieve superior 
performance uihen 
drawing sprites. 
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Listing 1. A 256-Color Sprite (Continued, on p. 38) 



/* 
/* 
/* 
/* 
/* 
/* 



CDMPLBMP.C - Routine to compile a 256-color bitmap image for 

Mode X or Mode 13h. 
Author: Matt Pritchard for Game Developer Magazine. 
Adapted from M0DEX108 



*/ 
*/ 
*/ 
*/ 
*/ 
*/ 



/* This stuff could go into a .h file */ 

/* Macro Definitions needed by Compile_Bitmap */ 

#define ucharf unsigned char far 
#define uchar unsigned char 
#define uint unsigned int 

#define hi_word( x ) (unsigned char) (x » 8) 
ttdefine lo_word( x ) (unsigned char) (x & OxOOFF) 

/* Prototypes for Compiled Bitmap Routines */ 

ucharf * Compile_Bitmap (ucharf *, int, int, int, int); 

void far pascal draw_compiled_bitmap (uchar far *, int, ints); 
void far pascal draw_compiled_bitmap_13h (uchar far *, int, ints); 



/*■ 



-*/ 



/* This function takes a Sprite that is stored in a two-dimensional array, such 
as char ImageData[32][32], and creates a buffer that contains the machine 
language code to quickly draw that image in Mode 13h or Mode X. 

The sprite data is stored line by line, from top to bottom. Each line 
is stored from left to right. A transparant color value is used to 
indicate which pixels are not part of the image and should not be drawn. 

Because Mode X supports various screen sizes, we must know the width 
of the screen a sprite will be displayed on in advance. For Mode 13h, 
that width is normally 320. 

When possible, two adjacent pixels will be drawn with one 16-bit MOV 
instruction. This results in smaller and faster code. 

This function allocates a buffer to hold the compiled code and 
returns a far pointer to it. The pointer need only be a char type 
pointer, since our assembly language routine does the actual calling of it. 

If the sprite is too big or the program has run out of memory, a null pointer 
is returned, otherwise a pointer to the compiled code is returned. 



ucharf * Compile_Bitmap (ucharf * thelmage, /* Far Ptr to the Sprite */ 

/* Width of the Sprite */ 

/* Height of the Sprite */ 

/* Transparent Color */ 

/* Width of the screen */ 



int X_width, 
int Y.width, 
int Trans_Color, 
int Screen Width) 
{ 

int x, y, p; 
int Words, Bytes; 
int bl, b2; 

uintVidOffset, Offset; 

int BytesPerLine; 

longCompiledBufferSize; 

longc; 

ucharf * theBuffer; 

int Num_ Planes; 
int Next.Pixel; 
int Code_Overhead; 



/* Loop counters for X, Y, and plane */ 

/* Count of each type of instruction */ 

/* Valid pixel flags */ 

/* Offsets for memory calculations */ 

/* Width of display in address bytes */ 
/* The size of the compiled sprite code*/ 
/* Counter for the code writing loop */ 

/* Pointer to the compiled code buffe */ 

/* The number of video planes (4 or 1)*/ 

/* The number of bytes between adjacent pixel*/ 

/* Size of any overhead code needed */ 



/* The variable Hode_X controls if we are compiling a sprite for Mode 13h or 
Mode X. For Mode X, we must split the image into four separate planes and 



over data compiled sprites, and is what 
we will now focus on. From this point 
on, when I refer to compiled sprites, I'll 
be talking about code-compiled sprites. 

For this article, I have written a 
routine in C , shown in L isting 1, which 
will compile a 256-color sprite for either 
M ode X or M ode 13h. I 've also provid- 
ed the assembly language setup routines 
needed to call the compiled sprite code 



The program 
generates actual 
machine language 
instructions that 
draiu the specific 
image on the 
screen. 



in L isting 2. W ith minor modifications, 
you should be able to use these routines 
in any program you wish. But I'll bet 
you aren't satisfied with just using the 
routines; you want to know what makes 
them tick. L et's take a closer look at the 
routines and discuss how they work. 

How it Works in a Program 

First, here's a quick overview of where 
the routines fit into a typical game. N or- 
mally, sprites are loaded from disk and 
placed into memory buffers either at 
startup or at some stopping point, such 
as a between rounds screen. W ith the 
sprite image in memory, the program 
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Listing 1. A 256-Color Sprite (Continued from p. 36) 



add plane switching code to the compiled sprite. If the value of Mode_X is 

0, we compile for Mode 13h, otherwise we compile for Mode X. */ 

int Mode J = -1; /* -1 = Node X, = Mode 13h */ 

if (Mode.X) { 

Num.Planes = 4; 

Next_Pixel = 4; 

Code_0»erhead = 20; 
} else { 

Num.Planes = 1; 

NextJ>ixel = 1; 

Code_0verhead = 5; 

} 

BytesPerLine = Screen_Width / Num_Planes; 

/* First, we pass through the bitmap and count up the number of adjacent pixel 
pairs and the number of single pixels. With this information, we will know 
how big a buffer to allocate. */ 
Words = Bytes = 0; 

for (p = 0; p < Num Planes; p++) 
{ 

for (y = 0; y < Y.width; y++) 
{ 

Offset = y * X_ width; 

for (x = p; x < X width; x+=Next_Pixel) 

{ 

/* Check the current pixel to see if it should be displayed */ 

bl = (thelmage[0ffset+x] != Trans_Color) ? -1 : 0; 

/* Check the next adjacent pixel (if there is one), and see if 

it should also be displayed */ 

if ((x + Next.Pixel) < X_width) { 

b2 = (theImage[Offset+x+Next_Pixel] != Trans.Color) ? -1 : 0; 
} else { 

b2 = 0; 

} 

/* Check for a pair of adjacent pixels, or a lone single pixel */ 

if (bl) { 
if (b2) { 

Words++; /* Another adjacent pixel pair */ 
x+=Next_Pixel; /* Skip over the next pixel */ 
} else { 

Bytes++; /* One more lone pixel */ 

} 



} 

} 

/* Determine how big a buffer we need for the compiled code, allocate it, and 
get a far pointer to it. */ 

CompiledBufferSize = Code_Overhead + (6 * Words) + (5 * Bytes); 

/* Here is where the users can insert their own error handling code */ 
if (CompiledBufferSize > 65535) { 

/* Error; compiled sprite would be too large (greater than 64K). */ 
return (0); 

} 

if ( (theBuffer = (ucharf *) malloc( (size_t) CompiledBufferSize)) == 0) { 

/* Error allocating buffer; out of memory. */ 
return (0); 

} 

/* Now, we go through the image again, this time creating the code to write into 
the compile code buffer. */ 



calls the compile.sprite routine with 
basic information about the sprite. 

The compiie.sprite function allo- 
cates a second memory buffer and fills it 
with machine language instructions 
made from the sprite data. T hen, it 
returns a pointer to the newly compiled 
code to the program. Depending on 
what is needed by your program, you 
can deallocate the original sprite buffer, 
freeing up additional memory. This 
compiling process isn't necessary each 
time the program is run; the code pro- 
duced is completely relocatable, so you 
could load and save the compiled sprites 
just like regular sprites. 

W hen the program needs to draw a 
sprite, it calls a special routine with a 
pointer to the compiled sprite code and 
the X,Y screen position at which the 
program will draw the sprite. This rou- 
tine first sets up the C PU 's registers 
with the correct position on the screen 
and then directly executes the compiled 
sprite code by jumping to it. T he com- 
piled sprite code then actually returns to 
the routine that called the special rou- 
tine. To the programmer, this process 
closely resembles calling a normal sprite 
drawing routine. 

How it Compiles the Sprite 

W hen we call the routine to compile the 
sprite, we send it the following informa- 
tion about the sprite: 

• A pointer to an array containing the 
sprite image 

• The width of the array in bytes 

• The height of the array in lines 

• The color value that will indicate 
transparent pixels 

• The width of the screen at the time 
the sprite will be drawn. 

The routine needs that last item, 
width of the screen, to compute the off- 
sets into display memory for each pixel. 
In M ode 13h, the width will always be 
320, but in M ode X (see my article 
"M ode X Revealed," Dec. 1994), it can 
vary according to the programmer's 
wishes. 

Compiling the sprite is a two- pass 
process. On the first pass, the sprite 
image is scanned, and each pixel is 
examined to see if it is a transparant 
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pixel. Every normal pixel is checked to 
see if it is adjacent to another normal 
pixel. This process generates a count of 
how many single pixels and adjacent 
pixel pairs make up the sprite. 

nee the pixels are counted, the 
routine calculates the size of the com- 
piled sprite code, and allocates memory 
to hold the code. Speaking of memory, 
how much memory do compiled sprites 
take up? T he size of the compiled sprite 
buffer will vary from image to image, 
but will be approximately 4 bytes per 
pixel drawn. Transparent areas produce 
no code. If a sprite is stored in a 32- by- 
32- pixel grid, but only about half the 
pixels are actually drawn, the grid will 
take up IK, while the compiled sprite 
should take up about 2K. 

The size varies because our routine 
creates code to draw two adjacent pixels 
with one instruction whenever possible. 
T he actual code created is: 
MOV [BX+offset], <16-bit constants 

which is 6 bytes long and draws two 
pixels. For pixels that are stuck by them- 
selves, the code created is: 

MOV [BX+offset], <8-bit constants, 

which is 5 bytes long and draws a single 
pixel. 

The routine makes a second pass 
through the image, this time generating 
actual code whenever a single pixel or 
pixel pair is encountered. If we are com- 
piling for M ode X , plane switching code 
is generated in between each video 
plane. Finally, instructions to return to 
the calling routine are added at the end 
of the buffer. 

Mode 13h vs. Mode X 

For M ode 13h, compiled code creation 
is very straightforward. B ut for M ode X , 
things get more complicated. In M ode 
X, we have to draw all the pixels on each 
video plane before going to the next 
video plane. Because of the video planes 
in M ode X, the two adjacent pixels we 
compile into one instruction are actually 
four pixels apart on the screen. I n addi- 
tion, we must include a 5- byte sequence 
to select the next video plane into the 



Listing 1. Continued from p. 38 



for (p = 0; p < Num Planes ; p++) 
{ 

for (y = 0; y < Y.width; 
{ 

Offset = y * X.width; 

for (x = p; x < X.width; x*=Next_Pixel) 

{ 



/* Check the current pixel to see if it should be displayed */ 

bl = (thelmage[0ffset+x] != Trans.Color) ? -1 : 0; 

/* Check the next adjacent pixel (if there is one), and see if it 
should also be displayed */ 

if C(x + Next_Pixel) < X.width) { 

b2 = (theImage[Offset+x+Next.Pixel] != Trans.Color) ? -1 : 0; 
} else { 

b2 = 0; 

} 

/* Generate code for a pair of pixels, or for a single pixel. */ 
if (bl) { 

VidOffset = (BytesPerLine * y) + ((x-p) / NumJ>lanes); 

if (b2) { /* Create Code to write Word Constant */ 

theBuffer[c++] = 0xC7; /* MOV word ptr */ 

theBuffer[c++] = 0x87; 

theBuffer[c++] = lo.wordf VidOffset ); /* BX'VidOffset */ 

theBuffer[c++] = hi_word( VidOffset ); 

theBuffer[c++] = (uchar) thelmage[0ffset+x]; 

theBuffer[c++] = (uchar) the!mage[Offset+x+Next_Pixel] ; 



x+=Next_Pixel; /* Skip over second pixel*/ 

} else { /* Create Code to write Byte Constant*/ 



theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 
} 

} 



0xC6; /* 
0x87; 

lo_word( VidOffset ); /* 
hi.word( VidOffset ); 
(uchar) thelmage[0ffset+x] ; 



MOV byte ptr 



*/ 
*/ 



if ( (Mode_X) && (p < 3) ) { /* Generate plane switching code*/ 



theBuffer[c++] 


= OxDO; 


/* 


ROL 


AL, 


1 


; Get New mask*/ 


theBuffer[c++] 


= OxCO; 












theBuffer[c++] 


= 0x13; 


/* 


ADC 


BX, 


cx 


; Add in Addr wrap*/ 


theBuffer[c++] 


= 0xD9; 












theBuffer[c++] 


= OxEE; 


/* 


OUT 


DX, 


AL 


; Select new Plane*/ 



} 

} 



/* Create exit code to return to the calling program */ 



theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 
theBuffer[c++] 



0x5D 
OxlF 
OxCA 
0x08 
0x00 



/* POP BP ; Restore BP */ 
/* POP DS ; Restore OS */ 
/* RETF8 ; Exit & Clean Up Stack*/ 



/* Return a pointer to the Buffer containing the Compiled Code */ 
return (theBuffer); 

} 
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Listing 2. Compiled Sprite Setup and Call Routine (Continued on p. 41) 



CDHPLBHP. ASM - Compiled Sprite Setup Si Call Routines for; 

Mode X or Mode 13h. 
Author; Matt Pritchard for Game Developer Magazine. 

Adapted from M0DEX108 
Assembler Used; MASM 5.10a 



.MODEL Medium 

.286 

.CODE 



General Constants & Macros 



up EQU WORD PTR 
dp EQU DWORD PTR 
fp EQU FAR PTR 

; ===== VGA Register Values Si Constants ===== 

VGA.Segment EQU OAOOOh ;Vga Memory Segment 



SC.Index 
SC.Data 



EQU 03C4h 
EQU 03C5h 



MAP.MASK.PLANE2 EQU 01102h 



PLANE.BITS 



EQU 



03h 



VGA Sequencer Controller 
VGA Sequencer Data Port 

Map Register + Plane 1 
Bits 0-1 of Xpos = Plane* 



DRAW.COMPILED.BITMAP (Compiledlmage, X.pos, Y.Pos) 



Sets up a call to a compiled bitmap in Mode X. 

ENTRY; Image = Far Pointer to Compiled Bitmap Data 

Xpos = X position to Place Upper Left pixel at 
Ypos = Y position to Place Upper Left pixel at 

EXIT; No meaningful values returned 



DCB.STACK 



DCB.Ypos 
DCB.Xpos 
DCB.Image 
DCB.STACK 



STRUC 
DU 7.7 
DD 
DW 
DW 
DD 
ENDS 



DS, BP 
Caller 

Y position to Draw Bitmap at 
X position to Draw Bitmap at 
Far Pointer to Graphics Bitmap 



Here, I assume it to be a table of word values 
which are stored in the current code segment. 



Mov BX, [BP]. DCB.Ypos 
Add BX, BX 

Mov BX, wp CS;Line_Offset[BX] 

Mov AX, [BP]. DCB.Xpos 
Mov CL, AL 
Shr AX, 2 

***** USER NOTE ***** MODIFY AS NEEDED ***** 

CURRENT PAGE is a DWORD pointer to the currently active 
Mode X video memory page. The first word is the offset 
into the video adaptor, and the second is the constant 
value of A000 - the VGA's graphics memory segment. 
Here, I assume it to be in DGROUP. 



BX = Ypos 

Scale BX to Word Offset 
Get Offset of Line Ypos 

Get UL Corner Xpos 
Save Plane # in CL 
X/4 = Offset Into Line 



Lds DX, dp CURRENT.PAGE 
Add BX, DX 
Add BX, AX 



Get Current VGA Page 
DS;BX->Start of Line 
DS;BX->Upper Left Pixel 



Select the first video plane, and set up the registers 
so the next 3 planes can be quickly selected. 



And 
Mov 
Shi 
Mov 
Out 
Inc 
Mov 
Clr 



CL, PLANE.BITS 

AX, MAP.MASK.PLANE2 

AH, CL 

DX, SC.Index 
DX, AX 
DX 

AL, AH 

CX 



CL = Starting Plane # 
Mask & Plane Select 
Select correct Plane 
VGA Sequencer ports 
Set Initial Vid Plane 
Point DX to SC.Data 
Mask for future OUT's 
CX = Constant 



Setup DS; BX = Upper left corner of Image in VGA memory 
BP = Local Stack Frame 
AL = OUT mask for Selecting video Plane 
CX = Constant value for ADC 
DX = SC.Data; VGA Sequencer Data Port 
AH = Destroyed 

SI.DI = Not modified during call 

Now we jump to the compiled code which actually draws the 
sprite. The compiled code will return to the caller. 



Jmp dp [BP].DCB_Image 
DRAW.COMPILED.BITMAP ENDP 



; Draw Sprite 



PUBLIC DRAW.COMPILED.BITMAP 

DRAW.COMPILED.BITMAP PROC FAR 

Push DS 
Push BP 
Mov BP, SP 



Save DS 

AX-DX are destroyed 
Set up Stack Frame 



Get DS; BX to point to (Xpos, Ypos) on the current 
display page in VGA memory 

***** USER NOTE ***** MODIFY AS NEEDED ***** 

Line.Offset is lookup table containing the start 
offset for each line in VGA display memory. 



DRAW.C0MPILED.BnMAP.13h (Compiledlmage, X.pos, Y.Pos) 



Sets up a call to a compiled bitmap in Mode 13h. 

ENTRY; Image = Far Pointer to Compiled Bitmap Data 

Xpos = X position to Place Upper Left pixel at 
Ypos = Y position to Place Upper Left pixel at 

EXIT; No meaningful values returned 
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compiled sprite buffer before we com- 
pile the pixels in the next video plane. 

I n L isting 1, the variable Mode.x 
controls the output of compiled sprite 
code. If it is nonzero, the image is bro- 
ken into four memory planes, and the 
plane switching code is added to the 
compiled sprite. If Mode.x is zero, then 
code for Hode_l3h is produced. 

Listing 2 shows two separate func- 
tions for drawing a compiled sprite— one 
for M ode X and one for M ode 13h. T he 
M ode X routine, drau.compiled.bitmap, 
loads registers with the screen address 
and plane-switching values. The M ode 
13h routine, drau_compiled_bitmap_13h, 
only needs to load registers with the 
screen address. 

Because compiling sprites reduces 
the process to its bare essentials, some 
limitations exist. You can't resize, rotate, 
or clip a compiled sprite to a rectangle. 
W ith normal sprites, you could write a 
different sprite drawing routine that 
performed these operations. 

Suggestions for 
Improvements 

The sprite compiling code I've present- 
ed here is only a start. There is no rea- 
son we can't include other capabilites in 
the compiled code. C lipping on one axis 
could be accomlished by ordering the 
compiled instrctions along that axis and 
using a jump table. Among the things 
that could be added are: 

• Add support for EGA and VGA 16- 
color sprites 

• Add support for SVGA and VESA 
modes 

• Add support for word-aligned writes 
to video memory 

• Add support for 32- bit instructions 

• Add support for vertical or horizontal 
clipping. 

I leave it to you, our reader, to 
decide where to take it. U ntil next time, 
happy coding! ■ 

M att Pritchard is a software developer for 
Lacerte Software in Dallas, Texas, and the 
author of M ODEX110, a comprehensive 
freeware M odeX library. You can reach 
him via email at matthewp@netcom.com 
or through G ame Developer magazine. 



Listing 2. Compiled Sprite Setup (Continued from p. 40) 



PUBLIC DRJU.C0NPILED.Bni1AP.13H 
DRAH.CQMPILED.BnnHP.13H PROC FAR 



Push DS 
Push BP 
Mov BP, 



SP 



Save DS 

AX-DX are destroyed 
Set up Stack Frame 



Get DS; BX to point to (Xpos, Vpos) in VGA memory 

***** USER NOTE ***** MODIFY AS NEEDED ***** 

Line.Offset is lookup table containing the start 
offset for each line in VGA display memory. 
Here, I assume it to be a table of word values 
which are stored in the current code segment. 



Mov BX, [BP].DCB.Vpos 

Add BX, BX 

Nov BX, wp CS;Line.Offset[BX] 

Add BX, BP] .DCB.Xpos 

Mov AX, VGA.Segment 

Nov DS, AX 



BX = Ypos 

Scale BX to Word Offset 
Get Offset of Line Vpos 
Get UL Corner of Sprite 

; Segment A000 

; DS; BX -> VGA memory 



Setup DS; 



SI, 
CX, 



BX = Upper left corner of Image in VGA memory 
BP = Local Stack Frame 
AX = Destroyed 

DI = Not modified during call 
DX = Not modified during call 



Now we jump to the compiled code which actually draws the 
sprite. The compiled code will return to the caller. 



Jmp dp [BP]. DCB.Image 
DRAW_C0MPILED_BITHAP_13H ENDP 
END 



; Draw Sprite 
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PUSH-BUTTON GONE DESIGN 



Has Pus h- 
Button Game 
Design Arrived? 




Selecting shadow colors for a specific background in MADS. The character's shadows are dif- 
ferent in each scene- to match the background art. 



If you think about it, what are the var- 
ious language compilers used by the 
software industry besides virtualized 
machine tools? H igh-level language 
compilers, advanced graphic render- 
ing systems, audio routine libraries— 
these are all tools that help game 
developers build the parts that com- 
pose a game product. 

H istorically, the complexity and spe- 
cialization of machine tools has grown as 
an industry grows. Look at any mature 
manufacturing industry, and the diversity 
of specialized tools supporting that indus- 
try is likely to boggle your mind. The 
younger the industry, the less rich are the 
toolsets you can use to build new products 
In the computer game industry, the 
pinnacle of the software development 
"machine tool" is the proprietary develop- 
ment platform. For example, Sierra 
Online's long-term success is due in no 
small part to the fact that it ventured into 



adventure games— a game genre with 
proven appeal. M ore importantly, it then 
developed SC I , its adventure game devel- 
opment system, which it used to mass 
produce new adventure games. 

Other early and somewhat legendary 
development systems include LucasArts's 
SCUMM and M icroprose's M ADS. 
Recently, there's been more talk about 
development platforms as everyone looks 
for a leg up on the competition. Sierra 
Online recently finished upgrading its 
aging development engine and redubbed it 
SCI 32, while newcomer Rocket Science 
drew envy with its ballyhooed Game Sci- 
ence system. 

The MADS System 

M icroprose sold the aging M A D S system 
to Sanctuary W oods, which turned around 
and overhauled the entire system. "The 
new system is called M 4D S," says M att 
G meson, executive producer and director 
of the advanced development group. 
G meson codesigned MADS when he was 
still with M icroprose. W hen he and a 
small development group moved en masse 
to Sanctuary W oods, they convinced their 
new employer to purchase MADS from 
M icroprose. 

The purpose behind MADS, 
M 4D S, and other development systems is 
to dramatically increase productivity. By 
reducing the number of programmers 
needed to complete any given project, the 
overall budget for a project is drastically 
reduced. G meson is clearly sold on the 
concept, "I had two goals. I wanted to give 
the end- user a better- looking, better-feel- 
ing game, and I wanted it to be more cost 
effective for us to produce these games." 

"With a development engine, pro- 



42 GAMEDEVELOPER -APRIL/MAY 1995 



gramming is where we save the most 
money. We don't need armies of pro- 
grammers to make everything happen." 
M icroprose's lushly animated Dragon- 
Sphere required only one person- year of 
programming time using M ADS, in com- 
parison to what G rueson estimates would 
take other companies, using less evolved 
development tools, three to four program- 
ming person- years to develop. "Based on 
what I know about the other development 
systems, their cost would be 50% to 100% 
higher than ours. If someone was trying to 
do everything DragonSphere does, and 
programming it from scratch, I can't even 
fathom how much time and money that 
would take." 

Collecting the Parts 

To design an effective development sys- 
tem you have to start thinking about any 
game as a collection of parts. A game con- 
sists of programming and content. Spend 
any time talking to designers of these 
development systems and the most com- 
mon phrase you will hear is "asset man- 
agement." Assets are your content, your 
media: PCX files, bitmaps, WAV files, 
and the like. 

On the software side, a game con- 
tains a collection of routines or functions 
that perform specialized tasks on different 
media types. The road toward creating a 
solid development system begins with a 
good library of such routines, both for 
graphics and sound. 

Get enough solid routines together, 
encapsulate them within an interface or 
within a highly abstracted (easy to learn 
and read) scripting language, and you have 
the core of a development system. The 
benefits are numerous. This structure 



forces you to reuse software assets, which 
saves money, and the routines that go into 
the development engine as parts tend to 
receive extra attention and become highly 
optimized overtime. 

Ideally, programmers can then focus 
on improving and adding new parts to the 
development engine, while (less expen- 
sive) teams of game designers and artists 
develop titles I n reality, programmers are 
still an integral part of any development- 
system- assisted team, even if they're there 
only to make the game do new tricks. 

The Ideal System 

T he ideal development system abstracts as 
much of the programming as possible so 
that artists and designers can use high- 
level, low-learning curve tools to build the 
game. "The important thing we kept in 
mind as we developed these tools was the 
programmers working on these tools were 
not the users. The customers were the 
production team. W e wanted each part of 
the team to be able to work with the sys- 
tem in the way that was natural to them. 
T he artists could do the art with the sys- 
tem, the game designers could do the 
writing and game design, and you didn't 
have programmers doing everything," says 
G rueson. 

M 4DS is a great example of how a 
fully developed, well-planned develop- 
ment works. The M 4 connotes four M s: 
multimedia, multiplatform, multiplayer, 
and multipoint. Building on MADS, 
G meson's team adds multimedia exten- 
sions, primarily streaming data handlers 
that let the system handle lossless video 
data. Says G rueson, 'The data streamer 
allows us to integrate audio, video, and 
collision data, like Rebel Assault did— 



David Gerding 

Fledgling though it 
moi| be, the gome 
industry is more thon 
reody for Soncfuory 
Woods's N4DS and 
Rochet Science's 
Gome Science, tuio 
systems thotherold 
the onset of push- 
button gome design. 
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ROLLING V U R OWN DEVELOPMENT SYSTEM 



Microsoft has released three Windows extensions that, taken together, could 
easily form the core of a simple development engine and there for the tak- 
ing. Sure, everyone knows about WinG, the quasi-double-buffering routine 
that speeds up graphics blitting under Windows. But go online and get ahold 
of WinToon, a set of routines that lets you superimpose a sprite on a win- 
dow playing an AVI file. Also, there's WaveMix, which will let you mix several WAV file 
sources in real time for multilayered sound effects. Of course, you must already be a Win- 
dows programmer or be willing to learn. Microsoft is providing these extensions to get 
developers to develop games for Windows, and they really are worth a look. 

Also, be sure to check out Klik and Play by Francois Lionet and Yves Lamourex. It's a con- 
sumer-targeted "game creator" that will teach you a lot about how to think of action 
games in terms of components. It's way cool. 

Finally, Director 4.0 has been released. If you're a PC or Windows fanatic, is new Windows 
version is a powerful, cross-platform development system in its own right, though you 
will likely need to learn Lingo, its scripting language, to do anything approaching a com- 
mercial-quality game. 



almost any type of data that we want to 
put into the stream. I t's fully virtualized. It 
even handles laying out the files in the 
correct and optimal order for the best 
access times" 

By keeping many of the requisite 
game structures represented in data rather 
than code, M 4DS also promises to be 
highly portable. "W e've got a M acintosh 
engine planned, and we've got most of the 
work done for a 3DO engine, though 
we're not sure we're going to proceed with 
that yet," G rueson says. 

Sanctuary W oods has also incorpo- 
rated a communications sublayer into the 
engine that will allow for distributed 
games where multiple players can interact. 
T he system is designed so that the world 
within it can be completely virtual. You 
can have players or nonplayer characters... 
all interacting within the same game uni- 
verse. T hese 'points' can be hooked up via 
modem, network, whatever. Because the 
communication layer is completely sepa- 
rate, we can write a communications dri- 
ver for practically any kind of communica- 
tion type we might need, including inter- 
active television," says G rueson. 

The Building Blocks 

The main components of M 4DS include 
a Sprite Editor, Animation Editor, Scene 
Editor, Object Editor, and Conversation 
E ditor. T he Sprite E ditor lets artists turns 



a series of sprites into any one of 24 pro- 
prietary formats that trade off various lev- 
els of compression depending on the func- 
tionality of the sprite required within the 
game. 

T he A nimation E ditor lets artists 
take backgrounds, sprites, and sounds and 
define the interaction between these 
assets. Explains G rueson, "If we have a 
sprite series of a moving car, a bouncing 
ball, and a kid walking down the sidewalk, 
plus a background of a street, the anima- 
tion will pull all those components togeth- 
er and optimize each of the sprite series to 
get the most animation in the least 
amount of disk space." 

Every asset is given a specific name, 
and those names are available to all pro- 
grammers, designers, and artists. W hen 
designing a development system, it's a 
good idea to follow G meson's lead and 
require common file naming conventions 
so that every member of the development 
team can quickly assess the contents of an 
asset by looking at the name. 

T he Scene E diting tool lets the 
designer and artists lay out all the ele- 
ments that compose a particular scene. 
Because M 4DS is primarily a graphic 
adventure development system, the 
metaphors and organizing principals it 
employs follow the structures and aesthet- 
ic typical to the adventure game genre. 
For example, the active screen elements or 



hot-spots common to all traditional 
graphic adventures get plenty of attention 
in M 4DS, including a hot-spot properties 
editor. 

The organizing components of any 
graphic adventure are collections of 
"scenes," and, subsequently, Scene Edit is 
where most of the graphical work gets 
done, reveals G rueson. Even though a 
development system is usually built upon 
an organizing metaphor such as scenes, it 
should also help artists and designers 
sweat the details, such as allowing artists 
to match a characters drop- shadow to 
each specific background. 

As for the core game logic, designers 
working on M 4DS use a proprietary 
scripting language modeled closely on C. 
According to G rueson, "W e chose that 
because you don't really have to train 
everybody in it.... ur programmers know 
it, and the syntax is already pretty well 
defined." 

Game Science 

On the cutting edge of development sys- 
tems, and offering an entirely different 
perspective is the G ame Science develop- 
ment system from Rocket Science. Rocket 
Science is doing graphically intensive, 
high- motion action arcade games, and the 
organizing metaphor is, appropriately, a 
world away from Sanctuary W oods's. 
M ost of the work is done in a layout pro- 
gram called Composer that is reminiscent 
of M acromedia D irector. T he C omposer 
lets you lay out the game in the form of a 
conditionally branching time line. W e call 
it T imeSpace," explains Sean C allahan, 
software engineer at Rocket Science. 
Callahan— one of the principal designers 
of Q uickT ime while he was at A pple — 
created the C omposer prototype. 

"Our main idea was to create a sys- 
tem so that game designers could create 
and develop without being programmers," 
says C allahan. "I n C omposer, the designer 
can do the layout, do the connections, and 
display it a reasonable level to see how the 
branches look and that kind of thing. It 
even tries to approximate the resolution of 
what the graphics will look like when its 
run on the target." 

The target is important to Callahan 
because Rocket Science's ambitious goal is 
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to make Game Science entirely platform 
independent and able to compile to a tar- 
get platform at the push of a button. As 
such, the system currently handles a limit- 
ed number of media types, including 
QuickTime movies, sprites, and digitized 
audio, though the system's abilities are 
changing to meet new demands. 

"Right now we are just looking at 
how we are going to let C omposer handle 
three-dimensional graphics. While our 
current system doesn't support true three- 
dimensional rendering right now, when 
we render the three-dimensional images 
on the SG I , part of the output we include 
in the file is three-dimensional reference 
information that is stored in one of the 
tracks in QuickTime. So, for example, if 
you're driving down a tunnel and you take 
a right turn... the car headlights seem to 
reflect on the wall in the right way because 
we've got enough of the three-dimension- 
al information about the tunnel in the 
QuickTime track," reveals Callahan. 

Rocket Science is just putting the 
finishing touches on the PC version of 



L oadstar, originally compiled for the Sega 
C D target. But all that hard work will pay 
off in the future, when subsequent titles 
are readily "compiled" for the PC in a 
fraction of the time most companies 
would spend to port a product. "The 
trickiest part in getting the compiler to 
port to the different platforms is figuring 
out all the timing issues with the different 
drives and the graphic hardware," says 
Callahan. 

The Argument Against 
Development Systems 

Sure, there are cost advantages to imple- 
menting a development system, and the 
allure of such seemingly elegant produc- 
tion is highly attractive. Is there a down- 
side? Yes and no. The potential downside 
is that games designed with a common 
development system will look and play 
alike. W hile the cookie- cutter similarity 
between Kings Quest 4-7 hasn't hurt the 
games' critical acclaim, sales, or profits, 
there will always be game purists demand- 
ing something new and different. Sierra 



can rightly claim that each new graphic 
adventure offers something the previous 
version did not, but the changes have been 
incremental, rather than revolutionary. 

The trick is to let the game designers' 
needs define the growth of the develop- 
ment system. T he tools that programmers 
periodically add to the development plat- 
form should answer designers' and artists' 
needs. It's simply a matter of keeping the 
developmental tail from wagging the dog. 

Push-button game design has 
arrived, and as the toolsets evolve, game 
artists, designers, and programmers will 
likely need to press fewer and buttons to 
see their dreams take form. Paradoxically, 
as the tools proliferate, it may take greater 
and greater genius in the future to build a 
game no one has played before. W hat a 
marvelous challenge! ■ 



D avid Gerding is a freelance writer 
who teaches interactive media at Columbia 
College of Chicago. 
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BOOK REVIEW 



in C 
The 



ramming 
and C++: 
Literature 



In the days before computers became 
a lifestyle and surfing was only done 
at the beach, you found computer 
books in dark corners of university 
libraries under "engineering." Not 
anymore. Eventually, every book- 
store, whether on campus or in a 
mall, had rows of computer books 
covering everything from Ada to Zmo- 
dem. But where were the hard-core refer- 
ences for programming games? 

I n the past two years, a surge of 
books that proclaims to reveal all these 
secrets has emerged. W hile none of them 
will make you an instant game program- 
ming superstar, any one of them will 
prove enlightening in some way. W hich 
ones are worth the time and money? I 
analyzed seven books on DOS game 
development according to their various 
strengths and weaknesses. 

Flights of Fantasy 

First of the group is F lights of F antasy 
(T he Waite Group, 1993, $34.95) by 
Christopher Lampton. T his 550- pi us- 
page book focuses on developing a 256- 
colorVGA flight simulator using Borland 
C++. Lampton states up front that the 
simulator won't compare to a high-end 
program like Falcon 3.0, but that it will 
give you the basic rudiments and structure 
to understand how these programs work. 

M ost of the book is devoted to the 
essentials of graphics: designing land- 
scapes, the mathematics of flying, how to 
remove hidden surfaces, and polygon clip- 
ping, for example. Lampton explains 
clearly about interfaces using joysticks, the 
keyboard, or a mouse. H e even manages 
to touch upon the process of adding 
Sound Blaster support to your games. 



The only major negative aspect 
about this book is its limited range of 
applicability. It may prove too daunting if 
you try to use the L ampton's book to pro- 
gram something more high-level, such as 
an arcade game. 

For flight simulator fans, though, 
this is the book. N ovice programmers may 
want to get this for its clarity of writing 
and its chapter on interfaces. C ertainly the 
information on three-dimensional model- 
ing will be of some benefit for those writ- 
ing first- person- perspective games. 

Verdict: Seemingly limited appeal 
but well written. W ould be of most 
interest to flight simulator fans. 

Creating Turbo C++ Games 

Clayton Walnum's Creating Turbo C++ 
G ames (Q ue C orp., 1994, $29.99) is a bet- 
ter book for the novice programmer than 
F lights of F antasy. T he 470-page book 
covers basic game programming and 
includes a variety of samples. I really liked 
that the book uses a low-end C ++ compil- 
er (Borland's Turbo C++, which sells for 
under $80). The games you learn how to 
develop are not sophisticated— card 
games, a dungeon quest, versions of W ari 
and Life— but they serve as a good spring- 
board for more detailed programs, and all 
use256-colorVGA to look sharp. 

W alnum's style is friendly and care- 
ful as he explains the various components 
in constructing a game and using C++. 
For those new to the language, he even 
includes a short primer in the back of the 
book explaining object-oriented program- 
ming and classes. 

The downside is that the games 
Walnum focuses on are very simple. Top- 
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ics like sound, joystick interfaces, and 
killer animation just aren't in the book, so 
ambitious game developers may require 
other sources of information to get to the 
next level of proficiency. Of all the books 
I reviewed, this one may be the best if you 
want to design strategy games. T he fun- 
damentals for programming strategy 
games are here; you just have to figure out 
how to use them. 

Verdict: Great book for C ++ 
beginners. 

Tricks of the Game 
Programming Gurus 

The most detailed, information- packed 
book of the seven books I looked at is 
Tricks of the Game Programming Gurus 
(SAM S Publishing, 1994, $45.00) by 
Andre LaM othe, John Ratcliffe, M ark 
Seminatore, and Denise Tyler. This is a 
must-have for beginning and intermedi- 
ate programmers, even if you don't have a 
CD-ROM player to access the enclosed 
disc. This 740-page book touches on 
everything: sound, artificial intelligence, 
networking, assembly language, graphics, 
and more. The focus is on developing a 
256-color VGA Doom-like game. Since 
this may be the most difficult type of 
game to develop, understanding the rou- 
tines here may make programming other 
types of games easier. 

T he writing style tends toward a 
sophomoric buddy- buddy style at times, 
but the information, tricks, and explana- 
tions more than make up for it. T he book 
presents information well, despite the fact 
that it starts with the topic of assembly 
language and then dives into matrix alge- 
bra two chapters later. These subjects, 



which are nightmarish yet vital, are han- 
dled well and made very accessible. 

The book is not perfect: nowhere is 
it clearly stated what compiler is recom- 
mended, though M icrosoft C 7.0 seemed 
to be the chosen tool (e-mail to one of 
the authors revealed that Watcom was 
also used). M any advanced topics, such as 
converting graphics routines to SVGA, 
are hinted at but then left as exercises for 
the reader. N o code is included for saving 
and restoring games, but unlike many of 
the other books here, at least the authors 
mention the topic. 

The accompanying CD-ROM is 
loaded not only with source code but 
many shareware games, such as Doom, 
and Blake Stone, and useful tools such as 
D igiPak and M idiPak to help you develop 
sounds for your programs. Also included 
is W arlock, a rudimentary D oom-like 
game whose code you can tinker with. 

Verdict: A must-have! I only wish it 
went into even more detail— like 
using DOS extenders and memory 
management. T he C D - RO M is 
loaded with source code, tools, and 
shareware. 

Action Arcade 
Adventure Set 

A newer book is Action Arcade Adventure 
Set (The Coriolis Group, 1994, $39.95) 
by D iana G ruber of T ed G ruber Soft- 
ware. H er book focuses on developing a 
256-color VGA side- scrolling arcade 
game similar to Commander Keen or 
D uke N ukem. Ted G ruber Software 
makes Fastgraph, a set of graphics rou- 
tines, and the book includes a subset of 
this package, called Fastgraph Light. 



Dean Oisboid 

If used to be difficult 
to find ani| program- 
ming boohs — much 

less game-specific 
ones — in your local 
bookstore. Nom.such 
texts are the order of 
the day. Here are the 
latest boohs on using 

C to develop games. 
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I have two points to make about this 
book. First, too much space is devoted to 
explaining the source code of the included 
tools, such as the sprite editor. Almost 
one hundred pages of the book are devot- 
ed to the tools' code, which is great if you 
want to modify those tools. H owever, 
most of us don't want to know how 
DeluxePaint or Renderman work— we 
just want to use them. W alnum also 
explains his graphics tools in T urbo C ++ 
Games, but he takes only 30 pages and 
then quickly returns to game design. 

Second, I feel the book reads like an 
advertisement for Fastgraph, as all the 
important functions the book describes 
come from that product. For example, the 
other books I reviewed explain how to 
write a joystick interface, but G ruber's 
doesn't; she suggests you use the Fast- 
graph routines for this event. N o other 
help is given on the topic. 

By relying on a product like Fast- 
graph, beginning- to intermediate- level 
developers don't learn how to write vital 
functions such as keyboard interrupt han- 
dlers. W hat may be worse is losing the 
ability— especially for the experienced 
programmer— to tweak any of the Fast- 
graph functions if there are speed bottle- 
necks. T he entire book relies so much on 
Fastgraph that to extract the information 
of writing a side-scrolling arcade game 
without it would be darn near impossible. 

T here is a flip side to this opinion, 
however. Some programmers prefer this 
reliance, as packages such as Fastgraph 
and Fastgraph Light let you can concen- 
trate on game design. The products take 
care of the difficult graphics routines, doc- 
ument them, and if you encounter prob- 
lems, you can call technical support. Fast- 
graph runs on most C/C ++compilers. 

Reactions aside, the most interesting 
readings were the headers for the game 
programs. The headers explain the struc- 
ture of the game and its components— 
and right there you get a ton of informa- 
tion. You can see what kind of thought 
and programming goes into a side- 
scrolling arcade game and how the plan- 
ning evolves. Also of interest are the final 
chapters on marketing and resources. 
H ow to sell your finished product is a 
topic not really touched by many of the 



books and the resources listing is a very 
nice addition. T he listing includes sources 
for custom music, sound effects, maga- 
zines that may interest developers, and 
other contacts. 

Verdict: Great or to be avoided, 
depending on whether you want to 
use Fastgraph as a primary graphics 
package. 

Programming 
Computer Games in C 

Robert B. M armelstein's book, Program- 
ming Computer Games in C (M&T Books, 
1994, $34.95) is similar to W alnum's 
Turbo C++ Games in that it describes the 
development of simple games in depth. 
The games in this book tend toward the 
"action arcade" side, putting it somewhat 
in competition with G ruber's book. H ow- 
ever, unlike G ruber's book, development 
doesn't rely on high-powered graphics 
routines— and it shows. In fact, many 
samples use 16-color EGA, which places 
this book about four years out of date. 

W hile each aspect of game construc- 
tion gets some mention, I felt the pro- 
grams and logic were too simplistic and 
that more efficient coding schemes could 
be used. M armelstein's use of bitmapping 
seems very inefficient when compared to 
L aM othe or G ruber. I n fact, M armelstein 
explains various design options and then 
chooses the easiest option, whereas the 
other authors might have chosen a more 
efficient yet difficult option. This book 
would have stood out two years ago, but in 
order to compete against the LaM othe 
tome it needs to include much more detail 
and ascribe to a higher level of game. 

Verdict: Well written but not chal- 
lenging enough. This could have 
been a much more useful book if 
M armelstein tackled, at least, a VGA 
platform and more advanced detailed 
games. W hen compared to the other 
books, it is painfully obvious that this 
is the weakest of the bunch. 

PC Game 

Programming Explorer 

I n contrast to M armelstein's and G ruber's 
books, D ave R oberts' P C Game Program- 



ming E xplorer (T he C oriolis G roup, 
1994, $34.95) takes the coding challenge 
and spells things out. T his 500- page book 
strives to develop one type of game: a top- 
to-bottom 256-colorVGA scroller, simi- 
lar to Apogee's Raptor (but more rudi- 
mentary in play). Roberts uses Borland C 
3.1 (4.0 will also work) as the compiler. 

T he book is very readable and covers 
the expected topics— interfacing, imple- 
menting VGA graphics and special 
effects, and sound, which makes it an 
excellent choice for beginners. But, as 
with L ampton's F lights of F antasy, the 
next technical step is up to you; to gener- 
alize beyond the type of game demon- 
strated would require some work. 

I ronically, T he C oriolis G roup pub- 
lished both Roberts's and G ruber's book, 
and my reaction while reading PC Game 
Programming Explorer was that this is 
what G ruber should have written. Every- 
thing, including a joystick routine, is 
clearly explained— with no reliance on 
prepackaged graphics routines. 

I greatly appreciated the chapter on 
what shareware and freeware program- 
ming tools to get, and whereto get them. 

Verdict: G reat book for beginners to 
low-intermediates. The narrow range 
of topics may prove too limited for 
more experienced programmers. 

Teach Yourself Game 
Programming in 21 Days 

As if one huge book weren't enough for 
him, Andre LaM othe wrote another one. 
Teach Yourself Game Programming in 21 
Days (SAM S Publishing, 1994, $39.99) is 
another required monster, coming in at 
950 pages. Topics are broken into daily 
chunks and each "day" ends with a sum- 
mary, questions and answers, a quiz, and 
exercise. H ealso throws in weekly reviews: 
a repetition of information that helps you 
retain the important stuff. Yes, the 
answers are in the back of the book. Asfor 
the compiler, LaM othe recommends 
M icrosoftC/C++7.0and M ASM 5.0. 

Unlike his previous book, LaM othe 
tackles a variety of game types instead of 
just a D oom clone. I n fact, he covers some 
unique topics: 

• Text adventures. LaM othe includes a 
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chapter on designing an old-fashioned 
text adventure. These games sound 
easy to program mainly because they've 
been around for so long. H owever, the 
implementation of these games is actu- 
ally difficult if you want to advance 
beyond the "G et fish," "E at fish" stage. 
H e explains the difference between 
lexical, syntactical, and semantic analy- 
ses—that is, parsing input into compo- 
nents, "understanding" the compo- 
nents of the input, and finally acting 
from the components if it's logical to 
do so— as he develops the adventure 
game Shadow Lands. As an additional 
demonstration and a wonderful bonus, 
the enclosed C D -RO M contains the 
source code for Zork 1. 

• D OS extenders M y gripe about his first 
book has been partially answered. 
LaM othe acknowledges DOS exten- 
ders and gives recommendations and 
tips for using them, but still doesn't 
actually show how to use them. 

• M arketing. W hile some of the other 
books I reviewed also mention market- 
ing, LaM othe explains how to protect 
your work by copyrighting and regis- 
tering your program with the copyright 
office. This is a nice touch. 

Since LaM othe has coauthored one 
of the other reviewed books, I 'm inclined 
to compare the two and see what is miss- 
ing from this newer book. T he most obvi- 
ous difference is that this book doesn't 
cover three-dimensional games. In fact, 
you might want to consider both books as 
a set— his first book covers three-dimen- 
sional games and this one explains every- 
thing else. Taken as such, the differences 
are minimal. 

Verdict: Another must-have. 
LaM othe has again written a book 
that includes so much information 
that other books can't match up. 
The CD-ROM not only has source 
code, it also has more tools and 
newer shareware games than the 
Tricks of the Game Programming 
Gurus disk. 

Gardens of Imagination 

C layton W alnum's Gardens of I magi na- 
tion: Programming 3D Maze Games in 



C/C ++ (T he W aite G roup Press, 1994, 
$34.95) follows up on his Flights of Fanta- 
sy by exploring the construction of maze 
games like Doom using Borland C/C++. 
Unfortunately, Walnum covers much the 
same ground as LaM othe and his coau- 
thors in their Gurus epic— but without as 
much detail. I n fact, the bulk of the 580- 
page book explores ways to produce a 
first-person, three-dimensional graphics 
background. I n the final chapter, W alnum 
rushes through the other aspects that go 
into a game. Implementing sound isn't 
even mentioned (although Walnum pro- 
vides neat code for an automap feature). 
The book therefore reads more like a 
H ow-to graphics manual rather than one 
for a game. 

n its own, the book is readable and 
useful, covering a variety of advanced top- 
ics such as ray tracing, ray and height 
casting, and the always vital code opti- 
mization. Of interest is the inclusion of 
Persistence of Vision, an incredible 
graphics generator and programming lan- 
guage, that has quite a following of its 
own. W alnum uses it to produce various 
parts of the maze background but even 
this interesting program is not enough to 
save the book. The focus stays too long 
on producing different maze types and 
snazzy background generation and not 
enough on game development. The book 
should have been called Producing 3D 
M azesin C/C++. 

Verdict: Bad timing kills this book. 
A year ago it would have been a 
groundbreaker. Though it covers 
similar material, it can't compare to 
Tricks of the Game Programming 
Gurus, especially when you factor in 
price and the quantity and quality of 
programs on the enclosed disk or 
CD-ROM . Beginners will not suf- 
fer, however, if this is the only book 
available at their bookstore. 

A Final Word 

All these books provide some good 
information. If you can afford just one 
book, invest in either of the LaM othe 
books; both give you a lot of informa- 
tion, code, and programs for your money 
and are the most current in terms of 



techniques. (T each Yourself Game P ro- 
grammi ng i n 21 D ays does have the 
newer versions of many shareware 
games, though.) 

For the complete beginner awed by 
the prospect of wading through either of 
LaM othe's books, my recommendation 
is Roberts' PC Game Programming 
Explorer for the depth and clarity of 
writing. For C++ aficionados, W alnum's 
Creating Turbo C++ Games gets the nod. 
It covers a variety of game types in a 
well-written manner. 

One caveat about these books is 
that they all claim to reveal the deepest, 
darkest secrets of game programming, 
which each one does to an extent. They 
all reach a certain point before waffling. 
N one of the books dared to show how to 
program SVGA or implement DOS 
extenders (and try to write a decent 
Doom clone without using some sort of 
extender). M any of these advanced areas 
were left as exercises for the reader to 
figure out. Also left as an exercise, sur- 
prisingly, is how to implement save and 
restore routines. Some of the books 
mentioned the topic but none offered 
any real code. 

Realistically, as games continue to 
push the envelope of hardware, a 
prospective game programmer just start- 
ing out will quickly hit a wall. Indeed, 
the in crowd of game developers will 
still remain "in" when it comes to the 
high level, SVGA, network and or 
modem- capable, Al-intensive, next gen- 
eration games. The fact that there is so 
much to learn and that new techniques 
are continually invented can be daunting 
to the beginner. But, with work, 
patience, and perhaps a little luck, the 
darkest secrets of game programming 
will be revealed. ■ 



D ean Oisboid, owner of Garlic Soft- 
ware, develops database applications and is 
a game designer. H e ran be reached via e- 
mail at 73717.2343@compuserve.com. or 
through G ame D eveloper magazine. 
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Tie Fighter, 
Part II 



Wayne Sikes 

Offer on initial, general 
look of LucasRrrs's Tie 

Fighter gome engine. 

Nop Sines digs 
deeper. This month, he 
scrutinizes the gome's 

doto files, os well os 

the structure of the 
Defender of the Empire 

add-on mission set. 



This month, we conclude our 
review of T I E F ighter by 
LucasA its Entertainment Com- 
pany. We've already looked at 
the T I E game engine in general, 
and I wrapped up last month by 
summarizing some of the data I 
found in the pilot file. This 
month, we'll go through some of the 
data found in the T I E mission files. 
LucasA rts released Defender of the 
Empire, TIE Fighter's add-on mission 
disk set, just as I began writing this 
review, so I'll also cover some of the mis- 
sion data I found in these new missions. 

The data files in the Defender of 
the Empire mission set were somewhat 
different from what I expected. The 
add-on missions for X-W ing, the first 
game in the Star W ars series, contained 
new game engines (the primary exe- 
cutable plus two overlay executables) in 



each mission set. TIE Fighter's mission 
set consists primarily of the new mission 
files plus some graphics and sound files 
for the new M issile Boat vehicle. The 
absence of a new game engine in the 
TIE add-on missions implies that the 
original game engine had the data for 
add-on missions built into it— the add- 
on mission sets will activate this data as 
needed. LucasA rts's strategy of creating 
only one game engine is good in that it 
forced the company to plan out the 
entire T I E game series from the start. 
This makes for cleaner and more reliable 
executables— as compared to game 
engines that must be updated with each 
release of new missions. Also, by not 
distributing new game engines with 
each add-on mission set, LucasA rts 
saves money on duplicating and distrib- 
uting mission disks, because the game 
engine files are quite sizable. 
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Listing 1. General Flight Group Parameters 



the 



Flight Group Name. 12-byte null-terminated array. 
Cargo 1 text. 12-byte null-terminated array. 
Cargo 2 text. 12-byte null-terminated array. 
Special Craft Position. 
Vehicle. l=X-Wing, 2=Y-Wing, 3=A-Wing, etc. 
Vehicles Per Wave. 

Starting Configuration. 0=Normal -> 8=Shields off 
Weapons. 0=None -> Magnetic Pulse 
Beam Weapons. 0=None -> 3=Decoy Beam 
Affiliation. 0=Rebel, l=Imperial, 2=Neutral, etc. 
Artificial Intelligence. 0=Novice -> 5=Super Ace 
Talk Flag. 0=Talk off. l=Talk on. 
Formation. 0=Vic -> 9=Vertical 
Number Of Waves. 
Player Position. 

Difficulty. 0=A11 Levels -> 5=<Hard Levels 
Arrival Mother Ship Flight Group. 
Arrival Method. 0=Hyperspace. l=Mothership 
Departure Mother Ship Flight Group. 
Departure Method. 0=Hyperspace. l=Mothership 



STRUCTURE DATA DESCRIPTION 

OFFSET (DECIMAL) TYPE* 

0-11 byte 

24-35 byte 

36-47 byte 

48 byte 

50 byte 

51 byte 

52 byte 

53 byte 

54 byte 

55 byte 

56 byte 
58 byte 
60 byte 
64 byte 
66 byte 
73 byte 

96 byte 

97 byte 

98 byte 

99 byte 

* "byte" references an unsigned character. 



TIE Mission File Overview 

The TIE F ighter mission files have a 
.TIE suffix. Refer to 'TIE Fighter, Part 
I" (Chopping Block, Feb./Mar. 1995) 
for information on how the battle and 
historical mission files are named as well 
as for listings of the mission files found 
in the original game distribution. The 
TIE mission files range in size from 
about 2,000 to 22,000 bytes. Each mis- 
sion file contains essentially all the flight 
group data, briefing text, radio messages, 
mission objective summaries, mission 
accomplishments, enemy opposition 
summaries, and instruction or warning 
messages that appear during a mission. 
X-W ing, on the other hand, had sepa- 
rate mission and briefing data files, and 
its mission and briefing text was 
nowhere as detailed asT IE Fighter's. 

The data for each flight group is 
contained in a 292- byte structure. All 
flight group structures are grouped 
together with the first structure begin- 
ning at offset 1CA (hex) in the mission 
file. The flight group structures, and 
hence the flight groups, are ordered in a 
one-up manner with the first flight 
group structure in the file as "flight 
group 0". 



T he T I E mission data is one of the 
most complex mission structures I have 
seen. Due to this complexity, I will be 
able to discuss only a few of the mission 
details. H opefully, the mission parame- 
ters I cover here will give you a broad 
idea of the types of data used by the T I E 
game engine for setting up missions. 

General Mission Parameters 

Listing 1 gives several parameters con- 
tained in the flight group structures. As 
you can see, each structure contains a 
large amount of flight group data, and 
we are just getting started! T he flight 
group N ame, C argo 1, and C argo 2 data 
are standard C null-terminated string 
arrays. The last character of each array 
must be null (0), so each string can con- 
tain up to 11 characters. 

T he Vehicle byte specifies the vehi- 
cle used by the flight group. Each game 
vehicle is referenced by a specific value— 
a value of 1 specifies an X-W ing, 2 is a 
Y-W ing, 3 is an A-W ing, and so on. 
TIE F ighter has many more vehicles 
than X-W ing. The Vehicles Per W ave 
variable specifies the number of vehicles 
that will appear with each wave of craft, 
and theN umber Of W aves byte specifies 



total number of waves allowed to 
appear. 

Several parameters specify the con- 
dition of the flight group vehicles when 
the group first appears in the game. T he 
Starting Configuration specifies normal, 
extra weapon, damaged, and special 
(shields off, hyperdrive off) configura- 
tions. T he W eapons variable gives the 
default weapon load and the Beam 
W eapons details any beam weapon load- 
out. The Beam Weapons data is espe- 
cially fun to alter because in the original 
game only Darth Vader had a Decoy 
Beam weapon. Now you can give your- 
self onetoo! 

T he A rtificial I ntelligence byte tells 
how good the pilots in the flight group 
are. You can set this level from Novice 
(not very good) to Super Ace. (I usually 
avoid the Super Ace settings because I 
get destroyed very quickly.) The Affilia- 
tion variable sets the allegiance of the 
flight group (such as Rebel, Imperial, or 
N eutral), and the T alk F lag toggles your 
ability to talk to or command the flight 
groups. (I usually turn this flag on when 
programming enemy flight groups so I 
can tell them to "go home" when I'm 
being beaten badly.) 

Every flight group can arrive and 
depart via hyperspace or a mothership. 
The Arrival and Departure M other Ship 
Flight G roup variables specify the flight 
group designated as the mother ships. 
The master controls for how vehicles 
arrive and depart are in the Arrival and 
D eparture M ethod bytes. I f you program 
a flight group to jump into hyperspace in 
the game, the vehicle you select for the 
flight group must have hyperdrive engine 
capability. 

Flight Group 
Start Conditions 

L isting 2 summarizes the flight group 
structure data that specifies when a 
group enters the game. I have given two 
start conditions the arbitrary label of Pri- 
mary and Secondary Start Conditions. 
Both start conditions function in the 
same manner. 

Several possible Primary and Sec- 
ondary Start Conditions exist. These 
conditions include an "always start" con- 
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dition (0), "the designated object must 
have arrived" (1), "the object must have 
been destroyed" (2), and so on. T he start 
condition depends on actions happening 
to another object. This object may be 
another flight group, a certain type of 
vehicle (X-W ing, Y-W ing, and the like), 
or a vehicle that has a specified allegiance 
(Rebel, Imperial, and so on). The condi- 
tion may also depend on a range of flight 
groups (flight groups 1 to 6, for exam- 
ple). The Primary and Secondary D epen- 
dency Type variables specify the type of 
object used for the start condition and 
the Primary and Secondary Start Data 
variables contain the data for the object. 
If the object is specified as a flight group, 
the data variables will contain the num- 
ber of the flight group. If the object is a 
type of craft, the data will specify the 
craft in the dependency condition. 

In addition to all the Primary and 
Secondary conditions, there can also be 
time delays that prevent a flight group 
from entering the game for a specified 
time interval. The Start M inute Delay 
counts in units of minutes, and the Start 
Second Delay counts in intervals of five 
seconds per data increment. 

The Primary And Secondary Logic 
Switch is interesting in that it specifies 
whether the player or game must accom- 
plish both the Primary and Secondary 
Start C onditions or just either one of 
them. W hen you set this switch to 0, a 
logical AND condition is specified and 
the game or player must meet both start 
conditions. A value of 1 specifies a logi- 
cal OR condition and only one of the 
start conditions must be met for the 
flight group to enter the game. 

Commanding 
The Flight Groups 

Commanding the flight groups is one of 
the most interesting yet complex areas of 
the T I E game engine. A lot of fore- 
thought went into the design of the 
algorithms used for the orders that can 
be given to a flight group. 

Each flight group can have primary, 
secondary, and tertiary orders. T he flight 
group structure stores each order as an 
18-byte structure with the three orders 
structures occurring sequentially in the 



flight group structure, beginning at off- 
set 104 (decimal) and ending at offset 
157 (decimal). Listing 3 summarizes 
some of the parameters found in each of 
the orders structures. N otice the detail 
given to each order. 

T he rder variable contains at least 
35 commanded orders. A value of 
commands the flight group to remain 
stationary, 1 instructs it to fly away, 2 
commands it to fly a loop, and so on. 
Any details associated with the order, 
such as time constraints or the number 
of loops to fly, are found in the Indica- 
torl, Indicator, and Indicator bytes. 
T he C ommanded Speed byte details the 
velocity for the flight group while it is 
carrying out the order. T he speed values 
increment in units of 10% of vehicle 
velocity. 

U p to four targets can be associated 
with each order. Each of these targets is 
specified in the Target X Data and Tar- 
get X Type variables (where X is targets 
1 to 4). The Target X Type variable 
specifies the type of target and the T ar- 
get X D ata variable contains the data for 
the target. Among the available target 
types are flight groups, types of craft (X- 
W ing, A-W ing, and so on), or craft hav- 
ing a specified allegiance (Rebel, I mperi- 
al, and the like). T he G lobal Player is a 
special target type. The Global Player 
type and its associated data are "modi- 
fiers" of other target objects (I'll discuss 
global data types in more detail later.). 
T he data for each target (T arget X D ata) 



Listing 2. Start Condition Data 



STRUCTURE 


DATA 


DESCRIPTION 


OFFSET (DECIMAL) 


TYPE* 




74 


byte 


Primary Start Condition. 0=Always. l=Arrived, etc. 


75 


byte 


Primary Dependency Type. 0=no dependence, l=flight 






group dependence, 2=i/ehicle type dependence, etc. 


76 


byte 


Primary Start Data. 


78 


byte 


Secondary Start Condition. 0=Always. l=Arrived, etc. 


79 


byte 


Secondary Dependency Type. 0=no dependence, l=flight 






group dependence, 2=i/ehicle type dependence, etc. 


80 


byte 


Secondary Start Data. 


82 


byte 


Primary And Secondary Logic Switch. 0=AND. 1=0R. 


84 


byte 


Start Minute Delay. 


85 


byte 


Start Second Delay. 



"byte" references an unsigned character. 
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Order. 0=remain stationary, l=fly home, 2=fly loop, 
3=fly loop and evade, 4=rendezvous, etc. 
Commanded Speed. 0=stopped -> 10=100'/, velocity 
Indicatorl. General timer, loop counter, etc. 
Indicator2. General timer, loop counter, etc. 
Indicator3. General timer, loop counter, etc. 
Target 1 Type. l=flight group, 2=type of craft, 
5=allegiance, 7=global, 8=flight group range 
Target 2 Type. l=flight group, 2=type of craft, 
5=allegiance, 7=global, 8=flight group range 
Target 1 Data, flight group, vehicle, etc. 
Target 2 Data, flight group, vehicle, etc. 
Targets 1 And 2 Logic Flag. 0=AND, 1=0R 
Target 3 Type. l=flight group, 2=type of craft, 
5=allegiance , 7=global, 8=flight group range 
Target 3 Data, flight group, vehicle, etc. 
Target 4 Type. l=flight group, 2=type of craft, 
5=allegiance, 7=global, 8=flight group range 
Target 4 Data, flight group, vehicle, etc. 
Targets 3 And 4 Logic Flag. 0=AND, 1=0R 



Listing 3. The Orders Structure 



STRUCTURE DATA DESCRIPTION 

OFFSET (DECIMAL) TYPE* 






byte 


1 


byte 


2 


byte 


3 


byte 


4 


byte 


6 


byte 


7 


byte 


CO 


byte 


9 


byte 


10 


byte 


12 


byte 


13 


byte 


14 


byte 


15 


byte 


16 


byte 



* "byte" references an unsigned character. 



can be a flight group number (assuming 
Target X Type specified flight groups), a 
vehicle type (assuming Target X Type 
called for a type of craft), an allegiance 
(assuming Target X Type called for alle- 
giance types), and so on. 

If this discussion of targets hasn't 
already been complex enough, let's add 
in the logic switches and global types. I n 
Listing 3, the data for targets 1 and 2 is 
grouped together, as is the data for tar- 
gets 3 and 4. T hese data were not placed 



STRUCTURE DATA DESCRIPTION 
OFFSET (DECIMAL) TYPE* 

158 byte 

159 byte 

160 byte 

161 byte 

162 byte 

163 byte 

164 byte 

165 byte 

166 signed char 



* "byte" references an unsigned character. 



in the orders structure randomly. T argets 
1 and 2 can be grouped together into a 
single target specification, and the same 
goes for targets 3 and 4. T he grouping is 
done by using two Boolean flags— the 
Targets 1 And 2 Logic Flag and the 
T argets 3 A nd 4 L ogic F lag variables. A 
value of commands that the two tar- 
gets function in an AND manner (both 
groups work together), and a value of 1 
signals an OR condition (the two target 
groups work independently). As I previ- 



ously mentioned, the Global Player tar- 
get type is a modifier of other targets. It 
is used in conjunction with these logic 
flags to modify the actions a flight group 
takes against a target. 

Let's look at an example to help 
simplify this targeting information. Let's 
assume you are flying a TIE Fighter and 
you want to program a flight group to 
attack all TIE Fighter vehicles— that is, 
all T I E F ighter craft except yours. H ow 
would you do this? First of all, program 
the flight group with the Attack Flight 
G roup orders (give the rder byte a 
value of 7). Let's arbitarily use targets 1 
and 2 for this order. W e would set Tar- 
get 1 Type to specify a type of craft (a 
value of 2 commands for a type of craft), 
and next we would set T arget 1 D ata to 
a value of 4, which would specify T I E 
Fighters. 

If we stopped right here, then all 
TIE Fighter craft, including yours, 
would be attacked. Set Target 2 Type to 
7, which invokes the G lobal Player type, 
and set Target 2 Data to 10 (decimal) 
which is the G lobal N ot Player option. 
Finally, set the Targets 1 And 2 Logic 
Flag to to force the and combination of 
targets 1 and 2. N ow all TIE Fighter 
craft except yours will be attacked. I real- 
ize that I have left out lots of detail here, 
but I hope you understand some of the 
logic used in commanding flight groups. 
(I said previously that the orders system 
in TIE Fighter is complex. W as I right?) 

Winning the Game 

T here are Primary (W in 1) and Sec- 
ondary (W in 2) win conditions that 
players must meet to win a mission. 
Refer to L isting 4 for a summary of the 
win and bonus conditions specified in 
the flight group structure. You'll see that 
I 've included a possible W in 3 condition, 
but I do not have much evidence that 
indicates this condition exists. 

The W in 1 Condition and W in 2 
Condition variables contain the condi- 
tions that must be met. The values in 
these conditions are the same as those 
found in the start condition variables. A 
value of 1 specifies that the group must 
have arrived, 2 means the group must be 
destroyed, and so on. T he W in 1 D etail 



Listing 4. Win and Bonus Variables 



win 1 Condition. l=created, 2=destroyed, etc. 

Win 1 Detail. 1=50'/,, 4=special vehicle, etc. 

Win 2 Condition. l=created, 2=destroyed, etc. 

Win 2 Detail. 1=50'/,, 4=special vehicle, etc. 
Possible Kin 3 Condition. 
Possible Kin 3 Detail. 

Bonus Condition. l=created, 2=destroyed, etc. 

Bonus Detail. 1=50'/,, 4=special vehicle, etc. 
Bonus Points. 1 increment = 50 points. 
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and W in 2 D etail bytes function as 
modifiers of the conditions. For exam- 
ple, if the condition specifies that a flight 
group be destroyed, the detail might 
modify this situation to mean that only 
the special craft in the group be 
destroyed to win. 

The Bonus Condition byte func- 
tions the same as the win condition vari- 
ables and the Bonus Detail functions the 
same as the win detail parameters. If the 
bonus condition and detail are met, 
bonus points can be awarded. The 
Bonus Points variable is a signed char 
value. Each increment in the value rep- 
resents 50 points. Since the bonus vari- 
able is a signed value, note that negative 
or penalty bonus points can occur. For 
example, if the bonus condition on your 
mother ship is that it be destroyed, a 
penalty of -10,000 points may be 
"awarded" if the enemy gets past you and 
takes out your mother ship. 

Want to Edit 
Some Missions? 

When analyzing the more detailed 
aspects of a game, I frequently write util- 
ities that help with my analysis. T he end 
result of my analysis of the T I E mission 
structures is a routine called TIEDIT. If 
you've read this far, then you know how 
complex the T I E mission data is. For 
this reason, I opted to write TIED IT in 
MS W indows because it is relative easy 
to implement list boxes, edit boxes, and 
the like in W indows. T he sheer number 
of mission items I could edit was enough 
to make me abandon any thoughts of a 
DOS- based TIE mission editor. Com- 
pletion of TIEDIT took longer than I 
anticipated because every time I tested it 
I would get "hooked" by the new mis- 
sions I was creating, and then I'd spend 
too much time playing the game! TIED- 
IT.ZIP is on CompuServe in the Flight 
Simulation Forum (GO FSFORUM ), 
Space Combat Library. 

We Have A Winner Here! 

As I've said before, LucasArts gaming 
products are generally well written and 
executed, and TIE Fighter is no excep- 
tion. T he level of detail L ucasA its devel- 
opers have given to TIE Fighter's mis- 



sion structures is fantastic, to say the 
least. This dedication to a product will 
considerably prolong TIE Fighter's life 
on the shelves via more add-on mission 
disks. I'd really like to see LucasArts 
release some form of the mission editor 
used in creating the retail missions. 
Obviously, the company might want to 
wait until it's done creating more add-on 
missions, but a retail LucasArts TIE 
mission editor could possibly extend the 
life of the game by years. ■ 



Wayne Sikes has been a computer 
hardwareand software engineer for the last 
10 years. H e has an extensive backgrond in 
C, C++, and assembly language program- 
ming. H e also has several years experience 
as a computer systems intelligence analyst, 
where he sped alized in deciphering and dis- 
assembling computer code on dassified gov- 
ernment projects. He has written numerous 
computer gaming help utitlities. You can 
reach him via e-mail at 70733. 1562@com- 
puserve.com or through G ame D eveloper. 
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It's a Sim, Sim, 
Sim, Sim World 



Alexander 
Antoniades 

When if was first 
released. SimCifii. 
from Naxis, was the 
sleeper of computer 
games. Now. numer- 
ous sequels later. 
Naxis is embarking on 
a new venture that 
will spawn a whole 
new SimWorld. 



Hs computer game companies 
expand, they often tend to lose 
their identity. The game 
responsible for the company's 
initial success gives way to 
other projects, and soon several 
creative teams are working on 
different games, some of which 
are successful and some of which aren't. 
The next thing you know they're hawking 
some D oom clone and you say to your- 
self, "This is the company that did x?" 
This is not the case with M axis 

At M axis, the apple never falls far 
from the tree. And that tree, of course, is 
SimC ity, the game of civic management 
that has not only gone on to sell more 
than one million copies across a number 
of platforms, but has also inspired count- 
less articles in famous periodicals, imita- 
tors aplenty, and everything short of a 
Nobel prize. SimC ity was followed by 
SimEarth, SimAnt, and SimLife, which 
extended the Sim product line and cor- 
nered a certain mental niche among 
gameplayers. 

I ndeed M axis is one of the names 
people are likely to invoke when they talk 
about the positive aspects of computer 
games. T he "software toy" that educates 
as it entertains became M axis's hallmark, 
and the company thrived on it. U sing the 
magic formula that combined provocative 
games with well-written manuals, excel- 
lent distribution, and some of the highest 
registration rates in the industry, M axis 
was often able to guide even the most 
complex game into six-figure sales. 

In 1994, after releasing the much 
anticipated sequel to SimC ity, SimC ity 
2000, theOrinda, Calif.- based M axis was 
becoming one of the largest computer 



game companies in the industry. It had 
grown to over 130 employees in five years 
and was moving toward going public. But 
first there were two development issues 
M axis had to deal with. 

First, M axis was still primarily a 
M acintosh developer in what was rapidly 
becoming a PC market. Co-founder W ill 
W right was a diehard M acintosh fan 
who developed most of M axis' games 
first on his favorite development environ- 
ment, the M acintosh. Unfortunately the 
sales breakdown favored the D S mar- 
ket by a three-to-one factor, so when 
DOS versions of M axis's games were 
often six months to a year behind the 
M acintosh versions the company ended 
up losing revenue. 

This is a problem that Brian Con- 
rad, technical director of M axis, has had 
to deal with. M axis developed SimC ity 
2000 for DOS and M acintosh simulta- 
neously, but, due to the complex nature 
of DOS platforms and trouble with the 
VESA video drivers, the DOS version 
still ended up three months behind the 
M acintosh version. 

For the long term, M axis hopes to 
come up with a cross- platform develop- 
ment environment that favors what it 
thinks will be the big market over the 
next couple of years— W indows. In the 
meantime its developers still use the stan- 
dard DOS development environment 
consisting of M iles Design sound drivers, 
Tenberry's DOS Extender, and Watcom 
C ++ 10.0. T he company is very close to 
moving to NT with Visual C++, but until 
M icrosoft can guarantee that what works 
under W indows will work under NT , 
M axis will hold off. Conrad expects that 
the company's last DOS products will be 
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the upcoming SimTown and Simlsle, 
unless running three-dimensional graphics 
under W inG invites a huge performance 
penalty. 

W hile M axis addressed the M acin- 
tosh vs. DOS issue, it was still struggling 
with another one— namely, the inter- 
locking nature of M axis' games, and the 
future of its cash cow, the SimC ity series. 
W hile SimC ity 2000 was a smash hit, 
M axis couldn't see a clear path for 
improving the series by adding new 
games to it. B ut most M axis games occu- 
pied some of the same intellectual real 
estate, which made them natural candi- 
dates to extend into each other. For 
example, one of the central strategies a 
player can use in SimC ity is to develop a 
mass transit system to help the city grow. 
In A -Train, a game M axis imported from 
thejapanese company A rtD ink, the goal 
is to help a community expand using a 
commuter rail line. I n the same vein, the 
monster towers of the future in SimC ity 
2000 are similar in nature to those players 
build in another Japanese game imported 
by M axis, SimTower. 

T hus the SimW orld project was 
born. The goal of this project was 
twofold. It would allow M axis to create 
future games with the capability to extend 
and merge into other preexisting and 
future games. And it would leverage Sim- 
City and the millions of hours worth of 
playtime that people have invested in 
SimC ity saved games into new markets. 

SimWorld 

"M ost of the project is formalizing the 
interface," says Jim M ackraz, director of 
M axis' newly formed C ore T echnology 
G roup. U sing his experience as a systems 
designer (M ackraz worked on the 
Amiga's Intuition interface), he and his 
group are trying to set the ground rules 
for the SimW orld project so that devel- 
opers can integrate them into future 
M axis games as they are making them. 

The first version of the SimWorld 
architecture will be based around games 
similar in scale to SimC ity 2000's data 
structure with one more layer of detail. 
This first stage of SimWorld will rely on 
static data exchange— that is, a foundation 
of users' saved games. M axis would like 



the first exchange to occur between W ill 
W right's "Project X," the likely successor 
to SimC ity 2000, and a three-dimensional 
helicopter rescue game that uses the same 
data set to create scenarios. In this case, 
players of Project X can use the helicopter 
game to perform rescues in cities they've 
created in Project X. 

For the next stage of the project, 
M ackraz envisions developers breaking 
down games into modular programs that 
could pipe data to one another. For exam- 
ple SimC ity 4000 might contain a Sim- 
C ity data server that would feed an editor 
client and a three-dimensional viewer, 
and a supplemental product like SimRail 
would include more data objects and sep- 
arate train builder client. 

M ackraz stresses SimW orld will not 
bea low-level infrastructure or an applica- 

r 




SimTower, a J apanese game, is just one 
of the many titles currently out that falls 
under the Sim umbrella. 



tion framework for games, but various 
games pieces that are connected. H e is 
currently leaning toward the lowest com- 
mon denominator of object technology, 
M icrosoft's L E and C M , but hasn't 
ruled out other technology. M axis sees 
this as the framework that will allow its 
developers to write common tools that 
can be used by any SimW orld game. 
D evelopers may also be able to build 
translation layers that can exchange Sim- 
W orld data with other gaming systems. 

As far as developer relations are con- 
cerned, the SimW orld project will go 
through three stages. SimWorld will first 
appear as an internal set of development 



libraries; next, M axis will release a software 
development kit to close partners; and 
finally, the company will put out a software 
development kit for any interested devel- 
opers Being an old operating systems guy, 
M ackraz is worried about letting a host of 
developers work on SimWorld because 
someone might create a killer app that 
cheats on the specs— and M axis would 
have to continue to support it. 

Everyone at M axis agrees that dri- 
ving this technology should be great 
games and not the other way around— the 
industry should never put technology over 
game play. M axis's goal is that all of the 
SimWorld components should feel like 
one world, and a synergy will exist 
between the games developers create using 
those components. "W e're going to title 
our way to an operating system," says Jim 
M ackraz, indicating that SimWorld will 
be extended with each new game. 

Project X 

SimC ity was born while W ill W right was 
working on a Commodore 64 action 
game called Raid on Bungling Bay for 
Broderbund in 1985. H e became interest- 
ed in the utility that he used to build the 
islands that were going to be bombed in 
the game. After he finished the game, he 
developed the first version of SimC ity for 
the Commodore 64. Unfortunately, 
Broderbund passed on the game, so it was 
never released. 

In 1987, Wright bumped into Jeff 
Braun, who wanted to start a game com- 
pany and was interested in helping devel- 
op SimC ity for the new 16-bit computer 
systems. W right started working on Sim- 
City for the Amiga and M acintosh. W hen 
SimC ity was released for the M acintosh in 
1989, Time magazine did a cover story on 
it, and the rest is history. 

Reflecting on critics and reporters 
using SimC ity as a socio-economic urban 
divining rod, W ill W right says, "I don't 
think anybody can build an accurate 
model of something as complex as a city. 
It's just too chaotic." But somehow that 
never stops him from trying. 

H is latest game, code-named Project 
X , is perhaps the closest he has come yet. 
It goes deeper than any of the previous 
SimC ity projects— in this game the player 
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will be able to interact in the city he or she 
builds. I got to seethisfirsthand. Using an 
existing SimCity 2000 saved game, Will 
W right demoed some of the working code 
for Project X. 

The game starts out on the same 
detail level as SimCity 2000 and then 
zooms down until one SimCity 2000 tile 
fills the screen. The player then creates 
people who will walk around and interact 
with each other. As the central character 
walks, the screen scrolls and follows his or 
her path. T his person will eventually meet 
other "simpeople," randomly determined 
by the surrounding socioeconomic condi- 
tions based on the SimCity 2000 data. 

Project X will likely determine the 
data structure that the first version of 
SimW orld will use. T hat data structure is 
such that managing the level of detail will 
be one of the biggest challenges in this 
project. W right estimates that in order to 
expand the current SimCity 2000 model 
to where the player can walk on every 
floor of every building will take about 
30M B to 40M B worth of datasets, which 



definitely makes this game CD-ROM 
based. The data will be loaded on the fly 
as the character walks all the way through 
game— the only data saved in the actual 
game will be where specific interactions 
occur. For example, if you stop to buy a 
newspaper, and the newspaper agent tells 
you his name isjoe, that will now be part 
of the saved game. 

The danger seems to be the inherent 
difficulty in saving large games. But 
W right remains confident that he can 
keep the data sufficiently compressed that 
size will not be an issue. T he current 
model would make a completely data- rich 
Project X saved game, that is, one where 
everything had been tracked or modified, 
at 3 gigabytes worth of data. But W right 
says playing the game every day for a 
month would only result in a saved game 
that was about 1M B in size, which isn't 
bad for that amount of playtime. 

Project X will put an important com- 
ponent of the SimW orld concept to the 
test— M axis's object-oriented data struc- 
ture, which the company hopes to use to 



extend its future games. Static objects in 
Project X can be embedded with behav- 
ioral characteristics for the simpeople. T he 
simpeople here aren't bitmaps, but stored 
pieces of component- based geometry with 
basic rules governing how they move. So 
objects can be introduced into an environ- 
ment that wasn't designed to support 
them. For example, a soccer ball could 
contain the rules of soccer, so when the 
soccerball object appears, a simperson 
would simply start playing soccer. 

Project X will provide the early 
foundation of the SimW orld model, and 
its success or failure will guide M axis into 
what is likely the most ambitious project 
this young industry has seen. It looks like 
M axis, using game play and not technol- 
ogy as it guide, will build the first inte- 
grated game environment. But in com- 
plex data models like the computer game 
market, no simulation can accurately pre- 
dict what will really happen. ■ 

Alexander Antoniades isG ame D evel- 
oper's editor- at- large 
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Hand-animated sequences distinguish a rou- 
tine fighting game and reward players for 
clearing each level. Pictured here is Mutant 
Rampage: Bodyslam, by Animation Magic for 
CD-i. 



Would You Like 
Virtual Buttery 
Flavoring 
With That? 



Hsthe processing power of com- 
puters and consoles becomes 
ever greater and the expecta- 
tions of game designers and 
consumers alike rise yet higher, 
the artist is forced to wade 
waters of increasing depth, 
treading further from shore 
while the comforts of two- frame sprite 
animation and tiled backgrounds recede 
in the distance. 

This is not a bad thing— far from it. 
Artists can now exercise greater creativity 
in game creation, flexing muscles that 
had previously been underused, given the 
limited graphics capabilities of yesterday's 
games. Yet at the same time, this new- 
found "freedom" brings with it new chal- 
lenges. Consumers want flash and sizzle. 
Glossy, cinematic title sequences and 
transitional animations are now all but 
obligatory. And with multimedia PCs 
already in an estimated 10 million U.S. 
households, the demand for "interactive 
movie" titles is growing. 

With digital entertainment acquir- 
ing more and more the characteristics of 
cinematic entertainment, game artists are 
being called upon to adopt the roles of 
the traditional film crew and to reinter- 
pret on their computers the functions of a 
movie set. W hether these complex "vir- 
tual sets" will be used throughout game- 
play or only in title and in-between 
sequences, their creation requires a 
diverse array of skills ranging from set 
designer and propmaster to lighting tech- 
nician and cinematographer, not to men- 
tion the technical demands of creating 
full-fledged animation. You can skirt the 
significance of these roles, certainly— you 
can approach an animation without giv- 



ing much consideration to viewpoint or 
composition or quick cuts— but the cost 
is in visual quality, and these days that 
can be a high price to pay. 

Lef s Go To The Movies 

I f we are, then, to adapt the roles of myr- 
iad film technicians to our task as com- 
puter artists, it is appropriate that for 
inspiration and guidance we turn to the 
movies in which their work comes 
together. We can benefit from their 
hard-earned experience as we usher in a 
new era of digital entertainment. 

W atching a good film is an immer- 
sive experience. T he willing viewer is car- 
ried along by the plot as by a current. 
Yet, though the storyline and action may 
seem to flow naturally, the film itself is 
an assemblage of artificial devices 
painstakingly combined for effect. In our 
quest to incorporate similar narrative 
sequences in the animations so common 
now in computer games, we would do 
well to note how and why effective cine- 
matic storytelling works. 

Few moviegoers dissect a film as 
they watch it, preferring to suspend dis- 
belief and enjoy the show. But cinematic 
technique can only be understood by 
observing a film rather than merely being 
swept along by it. bserve the cuts with- 
in a scene and note that though the view 
may switch from close-up to medium 
shot to tracking shot and back to close- 
up, the overall effect is still fluid; try to 
determine the placement of lighting 
required to achieve just that effect; pay 
attention to camera position and angle 
and the way they affect the mood or 
meaning of a shot. W hen the machinery 
behind the illusion is revealed, the magic 
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of cinema's ability to transport the audi- 
ence becomes all the more miraculous, 
the artistry of the film crew all the more 
admirable. 

The aesthetic considerations of the 
digital entertainment artist mirror those 
of the filmmaker, whether that artist is 
creating animations in two dimensions or 
three. For the most part, the creative 
decisions we must make transcend tech- 
nique or the actual tools an artist may use 
to create a scene; aesthetic considerations 
are the same regardless of the method we 
use to bring them about. W hether to 
work in two-dimensional or three-dimen- 
sional graphics, then, is chiefly a stylistic 
preference. Both require a demanding 
skill set and both rely, ultimately, on the 
artist's masterful control of the elements 
that combine to make a scene. 

If It Was Good 
Enough For Walt ... 

At Animation M agic, a fairly typical 
fighting game (CD-i's M utant Rampage: 
Body Slam) was jazzed up by means of 
between- play interviews with the combat- 
ants, a la TV wrestling. The artists han- 
dled the animation using traditional tech- 
niques—pen and paper— then scanned 
the results. Later, they used the computer 
to clean up and "paint" the hand- rendered 
frames. T he final look is of a comic book 
in motion, which suits the game to a tee. 

Fractal Design Painter offers anoth- 
er two-dimensional solution, with an 
"onionskin" function that lets you view 
several still frames simultaneously, like 
tracing-paper overlays, to aid in rendering 
animations. You can also create a new 
image by tracing an existing one, say a 
digitized photo or frame of film or video. 



Added to these helpful features is the 
ability to emulate natural media such as 
oil pastel or watercolor, creating effects so 
convincingly "hands-on" you expect to 
find finger smudges in the corners. 

The resulting hand-drawn look of 
such two-dimensional approaches can be a 
refreshing and effective departure from the 
sometimes sterile slickness or chunky pix- 
elization of computer graphics. If you're 
not already a fluent practitioner of tradi- 
tional animation techniques, however, this 
can be a tough way to start trying to flesh 
out your game graphics. W hile it certainly 
speeds up the inking and painting time of 
old-fashioned eel animation, two-dimen- 
sional software provides no help with cre- 
ating the illusion of space— perspective, 
foreshortening, lighting effects, cast shad- 
ows, and the like are all up to the artist to 
figure out— and if you elect to reframe a 
shot to depict it from a different view for 
heightened mood, you're talking about 
redrawing from scratch. 

Whaf s New 

Such limitations are nothing new; it's 
essentially the way all hand-rendered art 
has been made throughout history. H ow- 
ever, with the arrival of three-dimensional 
modeling and animation programs, the 
computer artist can leave behind the 
drudgy concerns of the draughtsman and 
concentrate on the creative challenges of 
visual narrative. And you don't need to 
sell your spare organs to scrape up the 
price of a Silicon G raphics workstation to 
take advantage of the power of three- 
dimensional animation, either. Programs 
like Caligari trueSpace, Visual Software's 
Visual Reality, 3D Studio from Autodesk, 
and many others are available for a variety 



David Sieks 

Gome animators con 
often fake their cue 
from nihot's happen- 
ing [ond been hap- 
pening] in Hollywood. 

The creative 
processes of movie 
mailing and game 
design are 
strikinglu. similar. 
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of platforms at down-to-earth prices, rel- 
atively speaking. Some are significantly 
closer to terra firma than others, but com- 
pared to a $100k SGI set-up these all 
qualify as terrestrial in price while still 
delivering out-of-this- world graphics 
effects. 

To a greater or lesser extent these 
programs all offer variations on the same 
glorious theme; your monitor becomes a 
window onto a virtual world of your cre- 
ation. Look at it from any angle. Light it 
brightly or dimly or fill it with fog. 
C hange the textures of its surfaces. D o 
what you will, then undo it and try it a 
different way. T he power is dizzying. 

The range of options is dizzying, 
too, and a formidable knowledge base is 
required to make full use of them. A 250- 
page manual is required, for example, to 
illuminate just the "new features" in 
Release 4 of 3D Studio. 

In the Director's Chair 

Regardless of whether you already have 
experience with two-dimensional or 
three-dimensional animation, or whether 
you are even now wondering what 
method you'll use to incorporate cinemat- 
ic sequences into your next game, giving 
some thought to film art techniques can 
probably help you add something special 
to that next project. 

Think About Lighting 

W hile a camera certainly needs light in 
order to capture images, any cinematogra- 
pher will tell you that lighting in a film 
serves more functions than mere practical 
illumination. Perhaps more than any other 
visual element, lighting sest the mood for 
a scene. Tension builds in darkness and 
shadows Flickering firelight can instantly 
make a scene appear cozy, or hellish, or 
both in turn. Shading can transform a face 
from angelic to monstrous. 

It's important for lighting effects to 
seem naturalistic, but H ollywood learned 
long ago that realism is secondary to 
results. In many shots, each major figure 
in a scene will be illumined by three or 
more lights: a key light for the defining 
highlights and shadows; fill light , used to 
soften the effect of the key light; and a 
backlight to separate the figure from the 



background. 

A two-dimensional animator can 
draw in the shading and highlights that 
seem appropriate. A three-dimensional 
animator must create them by positioning 
virtual lights within the virtual set.Three- 
dimensional modeling programs will 
allow you to set a brightness value and 
color for ambient light and position spot- 
lights to customize the illumination of 
objects and figures. W ith 3D Studio, you 
can even indicate where on an object you 
wish the highlight to appear and position 
the light accordingly. 

Think About 
Framing and Focus 

Viewpoint is a powerful and yet nearly 
invisible tool in the cinematographer's kit. 
Careful placement of the camera can 
underscore the relationships of figures or 
objects in a scene by visually grouping or 
separating them. Close-ups can focus 
attention on a detail or a fleeting facial 
expression, while an extreme long shot 
can establish locale or serve to make the 
clash of two armies seem puny against the 
scale of their surroundings. A high angle 
shot makes the subject appear smaller and 
might suggest weakness, whereas a low 
angle shot is often used to impart power 
and stature to the subject. 

Such varying viewpoints go unques- 
tioned by the audience— we don't even 
wonder why, for example, we are appar- 
ently looking down on a scene from a cor- 
ner near the ceiling— because of the nat- 
ural way in which viewpoint fits narrative 
structure and works to contribute to 
mood and meaning. But while the range 
of camera positions and angles is essen- 
tially limitless, their successful usage is a 
carefully considered decision. 

This is worth keeping in mind, as 
three-dimensional modeling and anima- 
tion software will enable you to position 
the viewpoint anywhere in relation to the 
scene, and it's easy to get carried away. A s 
with placement of lights, the virtual cam- 
era can be positioned visually or by means 
of Cartesian (X,Y,Z) coordinates to dic- 
tate a precise location. Involved camera 
movements are also facilitated by three- 
dimensional animation software. With 
two-dimensional methods, character ani- 



mation is readily manageable but it can be 
a real challenge to move the viewpoint 
around or through a scene. 

Another subtly powerful tool pro- 
vided by three-dimensional programs is 
the ability to affect lens optics. Just as a real 
camera can be outfitted with varying 
degrees of lenses to affect focal length, so 
can your virtual camera. The effect is a 
distortion of perspective, which affects 
the perception of depth in a scene. The 
ability to alter the appearance of a view in 
such a manner is crucial to the filmmak- 
er's art, and, again, it can be extremely 
difficult to duplicate with traditional, 
two-dimensional animation methods. 

Think About Editing 

The art of editing within a scene is per- 
haps the most significant aspect of narra- 
tive film technique, yet it is also the least 
noticeable. Editing is so intrinsic to the 
way we expect a scene to unfold that the 
details of each cut slide by without regis- 
tering on the consciousness of the viewer. 

Pay attention next time you watch a 
film to the way editing moves the plot 
along. bserve how shots are juxtaposed, 
how one leads to the next. N otice how 
movement is handled with editing. H ow 
long does each cut last, and how many go 
into a scene? 

Filmmakers have been working with 
these ideas throughout the past century 
and have become quite accomplished in 
their use. So adept are they in the manip- 
ulation of these techniques that, for the 
most part, we don't even notice them at 
work. Now, as digital entertainment 
strides toward new creative horizons, we 
can make use of their experience to 
improve our own art. 

If you want to add stunning anima- 
tion sequences to your next title— and of 
course you do— here are the first two 
steps: look into a three-dimensional mod- 
eling/animation program, and start pick- 
ing apart every movie you watch. h, and 
save me the aisle seat. 

D avid Sieks is a contributing editor to 
G ame D eveloper and isabsolutely nofun to 
go to the movies with. Contact him via e- 
mail at dsieks@arnarb.harvard.edu or 
through G ame D eveloper. 
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